On Tue, Aug 17, 2010 at 08:32:27AM +0200, Mario Bachmann wrote:
> Am Tue, 17 Aug 2010 08:30:21 +1000
> schrieb Dave Chinner <david@xxxxxxxxxxxxx>:
> > On Mon, Aug 16, 2010 at 06:22:36PM +0200, Mario Bachmann wrote:
> > > Hello,
> > >
> > > my kernel is
> > > Linux x2 184.108.40.206 #1 SMP Sun Aug 15 00:32:14 CEST 2010 x86_64 AMD
> > > Athlon(tm) 64 X2 Dual Core Processor 5600+ AuthenticAMD GNU/Linux
> > >
> > > I get a lot of Warnings with xfsdump-3.0.4 (booth, gentoo package
> > > 3.0.4-r1 and git-version):
> > >
> > > x2 ~/source/d/xfsdump/dump # ./xfsdump -l0 -L "Test" - /dev/sda2 |gzip -
> > > > /mnt/data2/dump_text.gz
> > .....
> > > ./xfsdump: WARNING: could not stat dirent .crack-attack ino 100663674:
> > > Das Argument ist ungültig: using null generation count in directory entry
> > bulkstat is failing, indicating an invalid option was passed.
> > > With the "old" version xfsdump-3.0.1, I get no warnings!
> > > xfsdump -l0 -L "Test" - /dev/sda2 |gzip - > /mnt/data2/dump301_test.gz
> > > xfsdump: using file dump (drive_simple) strategy
> > > xfsdump: version 3.0.1 (dump format 3.0) - Running single-threaded
> > ....
> > > xfsdump: Dump Status: SUCCESS
> > >
> > > And the file is 4,8 GB. All seems to be correct!
> > I can't see any changes between 3.0.1 and 3.0.4 that would explain
> > this. Did you run them on the same machine and kernel? Did you build
> > them with the same compiler? If everything is the same, then perhaps
> > you could bisect (only a few changes so should be quick) to point
> > out the offending change.
> After some testing, I think it is NOT a problem with xfsdump, but
> with the new kernel 220.127.116.11. First I must correct my last
> posting: xfsdump-3.0.1 DO have the same problem as xfsdump-3.0.4
> on kernel 18.104.22.168. It was just a coincidence that is worked one
> time without problems...
> Machines: I have two x86_64 and one x86. All machines have the
> same problems after I upgraded all three Kernels from 2.6.34.x to
> 22.214.171.124. So I believe, it is a problem with 126.96.36.199 or the
> combination of [188.8.131.52 & xfsdump].
> Compiler: I use "gcc (Gentoo 4.4.4-r1 p1.0, pie-0.4.5) 4.4.4".
> Testing List (on one machine only):
> works: x86_64, 184.108.40.206, xfsdump-3.0.1
> works: x86_64, 220.127.116.11, xfsdump-3.0.4
> failure: x86_64, 18.104.22.168, xfsdump-3.0.1 (worked only one time)
> failure: x86_64, 22.214.171.124, xfsdump-3.0.4
Ok, that makes more sense - we changed the way bulkstat works in
from 2.6.34 to 2.6.35 to correctly validate inode numbers being
passed in via bulkstat, and hence files unlinked during the dump run
could return EINVAL when validating the directory structure (as they
no longer exist). Is you system completely idle while the dump
is running, or are files being removed while the dump is running?