Am Tue, 17 Aug 2010 17:13:37 +1000 schrieb Dave Chinner <david@xxxxxxxxxxxxx>: > 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 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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
