LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Gene Heskett <gene.heskett@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: Greg KH <gregkh@suse.de>,
	stable@kernel.org, Justin Forbes <jmforbes@linuxtx.org>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Dave Jones <davej@redhat.com>,
	Chuck Wolber <chuckw@quantumlinux.com>,
	Chris Wedgwood <reviews@ml.cw.f00f.org>,
	Michael Krufky <mkrufky@linuxtv.org>,
	Chuck Ebbert <cebbert@redhat.com>,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	alan@lxorguk.ukuu.org.uk
Subject: Re: [patch 00/31] 2.6.20-stable review
Date: Tue, 20 Mar 2007 01:15:02 -0400	[thread overview]
Message-ID: <200703200115.05861.gene.heskett@gmail.com> (raw)
In-Reply-To: <20070319213647.GB9261@kroah.com>

On Monday 19 March 2007, Greg KH wrote:
>This is the start of the stable review cycle for the 2.6.20.4 release.
>There are 31 patches in this series, all will be posted as a response
>to this one.  If anyone has any issues with these being applied, please
>let us know.  If anyone is a maintainer of the proper subsystem, and
>wants to add a Signed-off-by: line to the patch, please respond with it.
>
>These patches are sent out with a number of different people on the
>Cc: line.  If you wish to be a reviewer, please email stable@kernel.org
>to add your name to the list.  If you want to be off the reviewer list,
>also email us.
>
>Responses should be made by Thursday March, 22, 15:00:00 UTC.
>Anything received after that time might be too late.

BINGO!  One of these 31 patches may be the guilty party that's playing
tricks with tar's mind.  I'm running 2.6.20.4-rc1 on an older athlon 
xp2800 with a gig of ram.

Amanda has gotten through the estimate phase and is now doing the backup.  
It will fail, out of tape.  Here is an amstatus output as its running 
right now.

coyote:/GenesAmandaHelper-0.5 3 planner: [dumps way too big, 350850 KB, must skip incremental dumps]
coyote:/GenesAmandaHelper-0.6 1 planner: [dumps way too big, 184977 KB, must skip incremental dumps]
coyote:/bin                   1 planner: [dumps way too big, 1110 KB, must skip incremental dumps]
coyote:/boot                  1        3m wait for dumping
coyote:/dev                   1 planner: [dumps way too big, 290 KB, must skip incremental dumps]
coyote:/etc                   1 planner: [dumps way too big, 18291 KB, must skip incremental dumps]
coyote:/home                  0     1018m wait for dumping
coyote:/lib                   3 planner: [dumps way too big, 11705 KB, must skip incremental dumps]
coyote:/opt                   1        5m wait for dumping
coyote:/root                  3 planner: [dumps way too big, 785963 KB, must skip incremental dumps]
coyote:/sbin                  1 planner: [dumps way too big, 10 KB, must skip incremental dumps]
coyote:/tmp                   4       32m wait for dumping
coyote:/usr/X11R6             1        2m wait for dumping
coyote:/usr/bin               1 planner: [dumps way too big, 339170 KB, must skip incremental dumps]
coyote:/usr/dlds              1 planner: [dumps way too big, 2140 KB, must skip incremental dumps]
coyote:/usr/dlds-misc         3        0m wait for dumping
coyote:/usr/dlds-rpms         1 planner: [dumps way too big, 3130 KB, must skip incremental dumps]
coyote:/usr/dlds-tgzs         1 planner: [dumps way too big, 10 KB, must skip incremental dumps]
coyote:/usr/games             0        0m wait for dumping
coyote:/usr/include           1 planner: [dumps way too big, 10557 KB, must skip incremental dumps]
coyote:/usr/kerberos          1        0m wait for dumping
coyote:/usr/lib               1 planner: [dumps way too big, 474409 KB, must skip incremental dumps]
coyote:/usr/libexec           2 planner: [dumps way too big, 11285 KB, must skip incremental dumps]
coyote:/usr/local             2      279m wait for dumping
coyote:/usr/man               1        0m wait for dumping
coyote:/usr/movies            2     7271m dumping     5485m ( 75.44%) (0:12:47)
coyote:/usr/music             1 planner: [dumps way too big, 2448290 KB, must skip incremental dumps]
coyote:/usr/pix               2       17m wait for dumping
coyote:/usr/sbin              1 planner: [dumps way too big, 3254 KB, must skip incremental dumps]
coyote:/usr/share             3 planner: [dumps way too big, 40514 KB, must skip incremental dumps]
coyote:/usr/src               3     6822m wait for dumping
coyote:/var                   1      366m wait for dumping

SUMMARY          part      real  estimated
                           size       size
partition       :  32
estimated       :  32                31973m
flush           :   0         0m
failed          :  18                16155m           ( 50.53%)
wait for dumping:  13                 8547m           ( 26.73%)
dumping to tape :   0                    0m           (  0.00%)
dumping         :   1      5485m      7271m ( 75.44%) ( 17.16%)
dumped          :   0         0m         0m (  0.00%) (  0.00%)
wait for writing:   0         0m         0m (  0.00%) (  0.00%)
wait to flush   :   0         0m         0m (100.00%) (  0.00%)
writing to tape :   0         0m         0m (  0.00%) (  0.00%)
failed to tape  :   0         0m         0m (  0.00%) (  0.00%)
taped           :   0         0m         0m (  0.00%) (  0.00%)
  tape 1        :   0         0m         0m (  0.00%) Dailys-19
8 dumpers idle  : not-idle
taper idle
network free kps:      6800
holding space   :     71118m (100.00%)
 dumper0 busy   :  0:00:00  (  0.00%)
 0 dumpers busy :  0:00:00  (  0.00%)
 1 dumper busy  :  0:00:00  (  0.00%)
----------------
The directory shown on line one of this report actually has:
[root@coyote /]# du -h /GenesAmandaHelper-0.5/
1.6G    /GenesAmandaHelper-0.5/config-bak
1.6G    /GenesAmandaHelper-0.5/

But line one above says its 350850 KB. 351 MB.  That directory and its 
contents have not been touched in at least a week, March 7th TBE and had 
766MB in it the last time I looked.  So a level 3 backup should be a very 
sparsely filled 65k directory list.

Then, looking at line 2, that tree is virtually identical and generally 
contains the same, or a few percentage points more data due to a change in 
the starting point of one of the amanda trees I'm doing external to 
amanda, so it may contain as much as 800MB right now.  As this is an 
active directory, with 20 megs or so new each night, I could believe a 
level 1 being 21MB maybe, certainly no more.  The last level 1 under a 
good kernel was 19MB according to the emails amanda sends me.  But it 
wants to backup 185MB tonight?

Now we are a little closer to finding this problem.  Or should I say this, 
because if I'm booted to either a working 2.6.20* kernel, or to one of the 
4 2.6.21-rc's I've tested, the data returned by a du -h is sane.  The 
figure I pasted in for the line 1 argument above is not, it's nearly 
double the actual size of that particular directory.  So it's conceivable 
that there are 2 problems as this is the first time a du -h has been 
effected too.

In any event, something tickled the monster, and its hungry.  This is a 
full-stop, show-stopper AFAIAC.

I'll cut that patch-2.6.20.4-rc1 in halves, and build 2 more test 
kernels tomorrow to start a bisect if no one has any better idea 
before then.

But its getting sleepy out now.

Thanks all.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
There is an order of things in this universe.
		-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

  parent reply	other threads:[~2007-03-20  5:15 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070319213047.710101653@mini.kroah.org>
2007-03-19 21:36 ` Greg KH
2007-03-19 21:37   ` [patch 01/31] Fix another NULL pointer deref in ipv6_sockglue.c Greg KH
2007-03-19 21:37   ` [patch 02/31] Fix rtm_to_ifaddr() error return Greg KH
2007-03-19 21:37   ` [patch 03/31] Fix user copy length in ipv6_sockglue.c Greg KH
2007-03-19 22:01     ` Chris Wright
2007-03-19 22:51       ` David Miller
2007-03-20  4:05       ` Greg KH
2007-03-19 21:37   ` [patch 04/31] gdth: fix oops in gdth_copy_cmd() Greg KH
2007-03-19 21:37   ` [patch 05/31] NetLabel: Verify sensitivity level has a valid CIPSO mapping Greg KH
2007-03-19 21:38   ` [patch 06/31] NETFILTER: nfnetlink_log: fix reference counting Greg KH
2007-03-19 21:38   ` [patch 07/31] IA64: fix NULL pointer in ia64/irq_chip-mask/unmask function Greg KH
2007-03-19 21:38   ` [patch 08/31] adjust legacy IDE resource setting (v2) Greg KH
2007-03-19 21:38   ` [patch 09/31] mm: fix madvise infinine loop Greg KH
2007-03-19 21:38   ` [patch 10/31] EHCI: add delay to bus_resume before accessing ports Greg KH
2007-03-19 21:38   ` [patch 11/31] initialise pi_lock if CONFIG_RT_MUTEXES=N Greg KH
2007-03-19 21:38   ` [patch 12/31] futex: PI state locking fix Greg KH
2007-03-19 21:39   ` [patch 13/31] nfs: nfs_getattr() cant call nfs_sync_mapping_range() for non-regular files Greg KH
2007-03-19 21:39   ` [patch 14/31] hrtimer: prevent overrun DoS in hrtimer_forward() Greg KH
2007-03-19 21:39   ` [patch 15/31] fix MTIME_SEC_MAX on 32-bit Greg KH
2007-03-19 21:39   ` [patch 16/31] fix read past end of array in md/linear.c Greg KH
2007-03-19 21:39   ` [patch 17/31] r8169: fix a race between PCI probe and dev_open Greg KH
2007-03-19 21:39   ` [patch 18/31] Fix extraneous IPSEC larval SA creation Greg KH
2007-03-19 21:39   ` [patch 19/31] : Fix GFP_KERNEL with preemption disabled in fib_trie Greg KH
2007-03-19 21:40   ` [patch 20/31] Fix ipv6 flow label inheritance Greg KH
2007-03-19 21:40   ` [patch 21/31] Copy over mac_len when cloning an skb Greg KH
2007-03-19 21:40   ` [patch 22/31] Fix sparc64 hugepage bugs Greg KH
2007-03-19 21:40   ` [patch 23/31] Fix page allocation debugging on sparc64 Greg KH
2007-03-19 21:40   ` [patch 24/31] IrDA: irttp_dup spin_lock initialisation Greg KH
2007-03-19 21:40   ` [patch 25/31] Input: i8042 - really suppress ACK/NAK during panic blink Greg KH
2007-03-19 21:40   ` [patch 26/31] hda-intel - Fix codec probe with ATI controllers Greg KH
2007-03-19 21:40   ` [patch 27/31] oom fix: prevent oom from killing a process with children/sibling unkillable Greg KH
2007-03-19 21:41   ` [patch 28/31] dio: invalidate clean pages before dio write Greg KH
2007-03-19 21:41   ` [patch 29/31] Input: i8042 - fix AUX IRQ delivery check Greg KH
2007-03-19 21:48     ` Dmitry Torokhov
2007-03-19 21:55       ` Chuck Ebbert
2007-03-20  4:18       ` [stable] " Greg KH
2007-03-19 21:41   ` [patch 30/31] fix deadlock in audit_log_task_context() Greg KH
2007-03-19 21:41   ` [patch 31/31] UML - arch_prctl should set thread fs Greg KH
2007-03-19 21:43   ` [patch 00/31] 2.6.20-stable review Greg KH
2007-03-20  5:15   ` Gene Heskett [this message]
2007-03-20 15:52     ` Greg KH
2007-03-20 19:59       ` Gene Heskett
2007-03-20 20:12         ` Michael Krufky
2007-03-21  2:56           ` Gene Heskett
2007-03-21  3:04           ` Gene Heskett
2007-03-21  3:39             ` Greg KH
2007-03-21  3:53               ` Gene Heskett
2007-03-25 16:30                 ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200703200115.05861.gene.heskett@gmail.com \
    --to=gene.heskett@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=cebbert@redhat.com \
    --cc=chuckw@quantumlinux.com \
    --cc=davej@redhat.com \
    --cc=gregkh@suse.de \
    --cc=jmforbes@linuxtx.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkrufky@linuxtv.org \
    --cc=rdunlap@xenotime.net \
    --cc=reviews@ml.cw.f00f.org \
    --cc=stable@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=zwane@arm.linux.org.uk \
    --subject='Re: [patch 00/31] 2.6.20-stable review' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).