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
next 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.