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

[Ingo Molnar]

* Gene Heskett <gene.heskett@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/