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]

Message-ID: <20070401065101.GA17729@elte.hu>
Date:	Sun, 1 Apr 2007 08:51:01 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Gene Heskett <gene.heskett@...izon.net>
Cc:	amanda-hackers@...nda.org, linux-kernel@...r.kernel.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)


* 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?

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

> 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?

> 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.
> 
> 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
-
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/