[Top] [All Lists]

[PATCH, RFC] xfs_repair - clear inodes in incorrect btree format

To: xfs-oss <xfs@xxxxxxxxxxx>
Subject: [PATCH, RFC] xfs_repair - clear inodes in incorrect btree format
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sat, 11 Jul 2009 00:17:36 -0500
User-agent: Thunderbird (Macintosh/20090605)
See also RH bug #510823:

This check in xfs_iformat_btree() tripped:

         * blow out if -- fork has less extents than can fit in
         * fork (fork shouldn't be a btree format), root btree
         * block has more records than can fit into the fork,
         * or the number of extents is greater than the number of
         * blocks.

leading to:

Jul 10 23:22:45 hermes kernel: Filesystem "dm-11": corrupt inode 2339503222
(btree).  Unmount and run xfs_repair.
Jul 10 23:22:45 hermes kernel: Filesystem "dm-11": XFS internal error
xfs_iformat_btree at line 625 of file fs/xfs/xfs_inode.c.

but repair finds nothing at all.  xfs_check, however, does flag the inodes
as problematic:

extent count for ino 2339503222 data fork too low (6) for file format

So I copied the xfs_check test into xfs_repair, and voila, it clears
these inodes.

But questions remain...

1) How'd it get into this state? ... but maybe more importantly...
2) Should these really get cleared?  It's possibly a sane extent list,
it's just that it -could- be in extents rather than btree format...
3) By the same token, should the kernel really be choking on it?

Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxxx>

diff --git a/repair/dinode.c b/repair/dinode.c
index 84e1d05..3fc6cac 100644
--- a/repair/dinode.c
+++ b/repair/dinode.c
@@ -1280,6 +1280,14 @@ process_btinode(
                        last_key = cursor.level[level-1].first_key;
+       if (*nex <= XFS_DFORK_SIZE(dip, mp, whichfork) / 
sizeof(xfs_bmbt_rec_t)) {
+               do_warn(_("extent count for ino %lld %s fork too low "
+                         "(%d) for file format\n"),
+                               lino,
+                               whichfork == XFS_DATA_FORK ? _("data") : 
+                               *nex);
+               return(1);
+       }
         * Check that the last child block's forward sibling pointer
         * is NULL.

<Prev in Thread] Current Thread [Next in Thread>