From: Gene Heskett <gene.heskett@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: New thread RDSL, post-2.6.20 kernels and amanda (tar) miss-fires
Date: Tue, 13 Mar 2007 23:31:53 -0400 [thread overview]
Message-ID: <200703132331.56140.gene.heskett@gmail.com> (raw)
In-Reply-To: <200703131436.33509.gene.heskett@gmail.com>
On Tuesday 13 March 2007, Gene Heskett wrote:
>On Tuesday 13 March 2007, Gene Heskett wrote:
>>Greetings;
>>Someone suggested a fresh thread for this.
>>
>>I now have my scripts more or less under control, and I can report that
>>kernel-2.6.20.1 with no other patches does not exhibit the undesirable
>>behaviour where tar thinks its all new, even when told to do a level 2
>> on a directory tree that hasn't been touched in months to update
>> anything.
>>
>>Next up, 2.6.20.2, plain and with the latest RDSL-0.30 patch.
>
>And amanda/tar worked normally for 2.6.20.2 plain.
>
>Next up, 2.6.21-rc1 if it will build here.
It built, it booted, and its busted big time. First, with an amdump
running in the background, the machine is so close to unusable that I
considered rebooting, but I needed the data to show the problem. I am
losing the keyboard and mouse for a minute or more at a time but the
keystrokes seem to be being registered so it eventually catches up.
Disk i/o seems to be the killer according to gkrellm.
But to give one an idea of the fits this is giving tar, I'll snip a line
or 2 from an amstatus report here:
coyote:/GenesAmandaHelper-0.6 1 planner: [dumps way too big, 138200 KB,
must skip incremental dumps]
Huh? 138.2GB? A 'du -h .' in that dir says 766megs.
coyote:/root 1 4426m wait for dumping
du -h says 5.0GB so that's ballpark, but its also a level 1, so maybe 20
megs is actually new since 15:57 this afternoon local. kmails final
maildir is in that dir.
This goes on for much of the amstatus report, very few of the reported
sizes are close to sane.
Now, can someone suggest a patch I can revert that might fix this? The
total number of patches between 2.6.20 and 2.6.21-rc1 will have me
building kernels to bisect this till the middle of June at this rate.
--
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)
Is a tattoo real, like a curb or a battleship? Or are we suffering in
Safeway?
next prev parent reply other threads:[~2007-03-14 3:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-13 8:28 New thread RDSL, post-2.6.20 kernels and amanda (tar) miss-fires Gene Heskett
2007-03-13 18:36 ` Gene Heskett
2007-03-14 3:31 ` Gene Heskett [this message]
2007-03-14 5:07 ` William Lee Irwin III
2007-03-14 5:44 ` William Lee Irwin III
2007-03-14 6:09 ` Gene Heskett
2007-03-14 6:19 ` William Lee Irwin III
2007-03-14 14:54 ` Gene Heskett
2007-03-14 21:49 ` Ray Lee
2007-03-15 3:12 ` Gene Heskett
2007-03-15 4:45 ` Ray Lee
2007-03-15 6:30 ` Gene Heskett
2007-03-15 5:28 ` [OT] " Willy Tarreau
2007-03-15 6:33 ` Gene Heskett
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=200703132331.56140.gene.heskett@gmail.com \
--to=gene.heskett@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox