On Sun, Aug 17, 2014 at 10:03:27PM -0400, Michael L. Semon wrote: > Hi! I had some phantom issues that are chasing me through this 3.17 > merge window period. While chasing those issues, I decided to do an > xfsdump of a v5/finobt XFS system rescued from PEBKAC issues. The > xfsdump completed rather prematurely, ending like this test case > output... > > xfsdump: dumping special file ino 4194523 mode 0x21b0 > xfsdump: dumping special file ino 4194524 mode 0x21b0 > xfsdump: dumping special file ino 4194525 mode 0x21b0 > xfsdump: dumping special file ino 4194526 mode 0x21b0 > xfsdump: dumping special file ino 4194527 mode 0x21b0 > xfsdump: ending media file > xfsdump: media file size 4512992 bytes > xfsdump: ending stream: 23 seconds elapsed > xfsdump: dump size (non-dir files) : 4452088 bytes > xfsdump: dump complete: 23 seconds elapsed > xfsdump: Dump Summary: > xfsdump: stream 0 /mnt/xfstests-scratch/blah.0.dump OK (success) > xfsdump: Dump Status: SUCCESS > > That looks fine for a lack of obvious error messages. However, it > should end like this: > > xfsdump: dumping regular file ino 13653551 offset 0 to offset 12154 (size 12154) > xfsdump: dumping regular file ino 13653555 offset 0 to offset 16554 (size 16554) > xfsdump: dumping regular file ino 13653556 offset 0 to offset 185 (size 185) > xfsdump: dumping regular file ino 13653557 offset 0 to offset 471 (size 471) > xfsdump: dumping special file ino 13653558 mode 0xa1ff > xfsdump: ending media file > xfsdump: media file size 1999127056 bytes > xfsdump: ending stream: 465 seconds elapsed > xfsdump: dump size (non-dir files) : 1963549104 bytes > xfsdump: dump complete: 465 seconds elapsed > xfsdump: Dump Summary: > xfsdump: stream 0 /mnt/xfstests-scratch/blah.0.dump OK (success) > xfsdump: Dump Status: SUCCESS What's the inode number progression of a successful dump at the point at which the incomplete dump ends? i.e. around inode 4194527? That number is one inode chunk short of 2^22, which implies that there is a failure or some kind moving from one AG to the next. The progrssion of inode numbers will tell me whether this is the case or not... > Bisect brought me here: > > root@oldsvrhw:/usr/src/kernel-git/linux# git bisect bad > c7cb51dcb0a38624d42eeabb38502fa54a4d774b is the first bad commit > [33mcommit c7cb51dcb0a38624d42eeabb38502fa54a4d774b[m > Author: Jie Liu <jeff.liu@xxxxxxxxxx> > Date: Thu Jul 24 12:18:47 2014 +1000 > > xfs: fix error handling at xfs_inumbers > From: Jie Liu <jeff.liu@xxxxxxxxxx> > To fetch the file system number tables, we currently just ignore the > errors and proceed to loop over the next AG or bump agino to the next > chunk in case of btree operations failed, that is not properly because > those errors might hint us potential file system problems. > This patch rework xfs_inumbers() to handle the btree operation errors > as well as the loop conditions. > Signed-off-by: Jie Liu <jeff.liu@xxxxxxxxxx> > Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx> > Signed-off-by: Dave Chinner <david@xxxxxxxxxxxxx> > > :040000 040000 ec78dc86468ee00df7a63bba97a135b8c6a84a95 2e447774a8f85b1b8d43ffa9fd28cbea3402d717 M fs > > Maybe Jeff's patch is doing its job. After all, on several successful > test runs, the kernel was sending messages like (paraphrased) "BUG: bad > state in page table" to remote syslog. The Pentium III PC has too > little memory (512 MB) to do this job. However, I think that the > xfsdump should last more than 23 seconds before causing issues. Memory should not matter for counting the number of inodes or extracting them from the kernel. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
