linux-kernel - Re: New thread RDSL, post-2.6.20 kernels and amanda (tar) miss-fires

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <200703132331.56140.gene.heskett@gmail.com>
Date:	Tue, 13 Mar 2007 23:31:53 -0400
From:	Gene Heskett <gene.heskett@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: New thread RDSL, post-2.6.20 kernels and amanda (tar) miss-fires

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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/