linux-kernel - Re: plain 2.6.21-rc5 (1) vs amanda (0)

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]

Date:	Sun, 01 Apr 2007 10:44:00 -0400
From:	Gene Heskett <gene.heskett@...izon.net>
To:	linux-kernel@...r.kernel.org
Cc:	Ingo Molnar <mingo@...e.hu>, amanda-hackers@...nda.org,
	amanda-users@...nda.org, Andrew Morton <akpm@...ux-foundation.org>,
	Adrian Bunk <bunk@...sta.de>
Subject: Re: plain 2.6.21-rc5 (1) vs amanda (0)

On Sunday 01 April 2007, Ingo Molnar wrote:
>* Gene Heskett <gene.heskett@...izon.net> wrote:
>> Hi Ingo;
>>
>> Running 2.6.21-rc5 tonight.
>>
>> It appears that as of 2.6.21-rc5, (actually anything with a 2.6.21 in
>> its version string) amanda is still a loser. [...]
>
>here 'is a loser' means: "tries to back up way too much stuff instead of
>doing a nice incremental backup like it does on 2.6.20.4", correct?

Yes, and as an additional clue, 2.6.20.4-rc1 does this, the later 2.6.20.4 
does not, so we have narrowed it down to one or more of the 31 patches in 
that gap.

>since it appears to be caused by a kernel change, this is a serious
>regression in v2.6.21-to-be.

Yes, that's why I'm fussing now, hopefully before this gets into the field 
as a final version.

>> Good, 2.6.20.4 was running
>> sendsize.20070331000507.debug:sendsize[762]: time 248.361: getting
>> size via gnutar for /usr/music level 0
>> sendsize.20070331000507.debug:sendsize[762]: estimate time for
>> /usr/music level 0: 1.239 sendsize.20070331000507.debug:sendsize[762]:
>> estimate size for /usr/music level 0: 2466050 KB
>> sendsize.20070331000507.debug:sendsize[762]: time 249.605: getting
>> size via gnutar for /usr/music level 1
>> sendsize.20070331000507.debug:sendsize[762]: estimate time for
>> /usr/music level 1: 0.027 sendsize.20070331000507.debug:sendsize[762]:
>> estimate size for /usr/music level 1: 80 KB
>>
>> Bad, 2.6.21-rc5 is running
>> sendsize.20070401000504.debug:sendsize[18465]: time 167.371: getting
>> size via gnutar for /usr/music level 0
>> sendsize.20070401000504.debug:sendsize[18465]: estimate time for
>> /usr/music level 0: 0.398
>> sendsize.20070401000504.debug:sendsize[18465]: estimate size for
>> /usr/music level 0: 2466050 KB
>> sendsize.20070401000504.debug:sendsize[18465]: time 167.773: getting
>> size via gnutar for /usr/music level 1
>> sendsize.20070401000504.debug:sendsize[18465]: estimate time for
>> /usr/music level 1: 0.049
>> sendsize.20070401000504.debug:sendsize[18465]: estimate size for
>> /usr/music level 1: 2448290 KB
>>
>> Yesterdays run, dated 20070331000507 were correct as that directory
>> hasn't been write accessed in a couple of months.
>>
>> Today's, dated 20070401000504, shows totally bogus figures for exactly
>> the same data.
>
>'totally bogus figures' needs to be analyzed further. What system call
>or library calls returns incorrect data?

Tar is used with the output sent to /dev/null, to obtain those numbers 
since the last $level figures and these are then assigned to $level + 1.  
Each disklist entry gets scanned twice during the estimate phase, once 
for a level 0 reference, and once for a "since $timestamp" value.  I'm 
not sure if the timestamp in the /etc/amandates file is used, or the 
timestamp on the indice file amandates names is used. Amanda then decides 
what to do next in an attempt to balance the tape usage run to run, and 
not let a needed level 0 ever get more than 1 run behind if amanda can 
help it.  It will drop incrementals to meet that goal if it has to with 
the current order I have setup in my amanda.conf.

>> This effect I have isolated down to something in the 31 patches from
>> 2.6.20.4 to 2.6.20.5-rc1, but I'm going to need additional guidance in
>> setting up the bisect to find it.  If indeed its a kernel problem.

And I miss-quoted the above, its the 31 patches between 2.6.20.3 and 
2.6.20.4-rc1.  Then for some reason I don't grok, 2.6.20.4 is good again.

>> This same effect has been present in any and every 2.6.21.* release.
>
>maybe it's some sort of timestamp problem, on the FS level?
>
>	Ingo

I wasn't aware of a 'timestamp' problem on the FS level ever being 
discussed at any length here on lkml.  As far as my checking, I'm limited 
to what "ls -lc?" tells me, and those figures seem to be sane.

Is there additional data present now that could screw up tar, and do it 
without being obvious to ls?  I don't know. :-\

-- 
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)
We have only two things to worry about:  That things will never get
back to normal, and that they already have.
-
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/