Re: xfsdump completes very prematurely in low RAM, commit found

Dave Chinner
2014-08-18T02:41:21Z

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@oracle.com>
> Date: Thu Jul 24 12:18:47 2014 +1000
>
> xfs: fix error handling at xfs_inumbers
> From: Jie Liu <jeff.liu@oracle.com>
> 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@oracle.com>
> Reviewed-by: Dave Chinner <dchinner@redhat.com>
> Signed-off-by: Dave Chinner <david@fromorbit.com>
>
> :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@fromorbit.com