Re: xfsdump-3.0.4 problems

[Mario Bachmann <mbachman@stud.uni-frankfurt.de>]

Am Tue, 17 Aug 2010 17:13:37 +1000
schrieb Dave Chinner <david@fromorbit.com>:

> 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@fromorbit.com>:
> > 
> > > On Mon, Aug 16, 2010 at 06:22:36PM +0200, Mario Bachmann wrote:
> > > > Hello, 
> > > > 
> > > > my kernel is
> > > > Linux x2 2.6.35.2 #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 2.6.35.2. First I must correct my last
> > posting: xfsdump-3.0.1 DO have the same problem as xfsdump-3.0.4
> > on kernel 2.6.35.2. 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
> > 2.6.35.2. So I believe, it is a problem with 2.6.35.2 or the
> > combination of [2.6.35.2 & 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, 2.6.34.4, xfsdump-3.0.1
> > works:   x86_64, 2.6.34.4, xfsdump-3.0.4
> > failure: x86_64, 2.6.35.2, xfsdump-3.0.1 (worked only one time)
> > failure: x86_64, 2.6.35.2, 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?
> 
> Cheers,
> 
> Dave.

I would call my system idle, when I use xfsdump. No rm or mv operations 
are running while the dump. The first machine has a dual core 2.9 GHz and
8 GB of RAM and the filesystems are not really big (~10GB used). The second 
machine has a dual core 2 GHz and 2 GB of RAM. 

It does not matter if I dump the running root partition or the extra 
home partition (even not logged in with a user, so there should be absolutely 
no changes to the files, also I did a sync before the dump). 

What I tested now: After downgrading to 2.6.34.4 on both x86_64, xfsdump worked again, 
but that is no solution to use an old kernel!

To describe the result on 2.6.35.2 again clearly: xfsdump produces a dump where 
some gigabyte of data are simply missing. I think about 30% of all files are 
missing. 

Mario

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs