public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Gene Heskett <gene.heskett@verizon.net>
Cc: amanda-hackers@amanda.org, linux-kernel@vger.kernel.org,
	amanda-users@amanda.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Adrian Bunk <bunk@stusta.de>
Subject: Re: plain 2.6.21-rc5 (1) vs amanda (0)
Date: Sun, 1 Apr 2007 08:51:01 +0200	[thread overview]
Message-ID: <20070401065101.GA17729@elte.hu> (raw)
In-Reply-To: <200704010100.19016.gene.heskett@verizon.net>


* Gene Heskett <gene.heskett@verizon.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

  reply	other threads:[~2007-04-01  6:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-01  5:00 plain 2.6.21-rc5 (1) vs amanda (0) Gene Heskett
2007-04-01  6:51 ` Ingo Molnar [this message]
2007-04-01 14:44   ` Gene Heskett
2007-04-01  7:33 ` Ray Lee
2007-04-01 15:41   ` Gene Heskett
2007-04-02  4:20     ` Gene Heskett
2007-04-02  4:31       ` Dave Dillow
2007-04-04  4:34         ` Dave Dillow
2007-04-04  8:45           ` Ingo Molnar
2007-04-04 17:42             ` Andrew Morton
2007-04-04 18:17               ` Dave Dillow
2007-04-04 20:29                 ` Andrew Morton
2007-04-04 21:55                   ` Dave Dillow
2007-04-05  0:49                     ` Gene Heskett
2007-04-09 15:33           ` Gene Heskett
2007-04-09 15:59             ` Dave Dillow
2007-04-09 16:12               ` Gene Heskett
2007-04-09 16:30               ` Gene Heskett
2007-04-09 16:00             ` Ingo Molnar
2007-04-09 17:05               ` Gene Heskett
2007-04-09 17:50                 ` Ingo Molnar
2007-04-09 19:58                   ` 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=20070401065101.GA17729@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=amanda-hackers@amanda.org \
    --cc=amanda-users@amanda.org \
    --cc=bunk@stusta.de \
    --cc=gene.heskett@verizon.net \
    --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