public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: xfs-oss <xfs@oss.sgi.com>
Subject: [PATCH, RFC] xfs_repair - clear inodes in incorrect btree format
Date: Sat, 11 Jul 2009 00:17:36 -0500	[thread overview]
Message-ID: <4A582070.9040907@sandeen.net> (raw)

See also RH bug #510823:
https://bugzilla.redhat.com/show_bug.cgi?id=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@sandeen.net>
---

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") : _("attr"),
+				*nex);
+		return(1);
+	}
 	/*
 	 * Check that the last child block's forward sibling pointer
 	 * is NULL.

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

             reply	other threads:[~2009-07-11  5:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-11  5:17 Eric Sandeen [this message]
2009-07-13  9:33 ` [PATCH, RFC] xfs_repair - clear inodes in incorrect btree format Olaf Weber
2009-07-13 14:34   ` Eric Sandeen
2009-07-15 13:07 ` Christoph Hellwig
2009-07-15 13:56   ` Eric Sandeen
  -- strict thread matches above, loose matches on Subject: below --
2009-08-07 13:00 Zoran Cvetkovic
2009-08-07 14:13 ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A582070.9040907@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox