From: Eric Sandeen <sandeen@sandeen.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH, RFC] xfs_repair - clear inodes in incorrect btree format
Date: Wed, 15 Jul 2009 08:56:24 -0500 [thread overview]
Message-ID: <4A5DE008.5040103@sandeen.net> (raw)
In-Reply-To: <20090715130705.GA27973@infradead.org>
Christoph Hellwig wrote:
> Adding this check is certainly better than having nothing, but I would
> be much happier if we could do something.
>
> On Sat, Jul 11, 2009 at 12:17:36AM -0500, Eric Sandeen wrote:
>> 1) How'd it get into this state? ... but maybe more importantly...
>
> End of last year lachlan had case that looked a bit like this where
> we had problems resetting the fork state.
>
>> 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...
>
> That is indeed the the most likely case. Do you still have a metadump
> with this problem around? We should probably sanity-check for a valid
> looking extent format inode and then process it as such.
yep I do... and the user was able to perfectly copy off the files by
disabling the kernel check, FWIW. So in this case it really was OK.
>> 3) By the same token, should the kernel really be choking on it?
>
> Well, not choking could cause all kinds of harm by treating it as
> a btree inode while it's not. We could try to apply a very careful
> variant of 2) above, but I'd really rather leave that kind of thing
> to repair.
Yep, probably best.
>> + 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);
>> + }
>
> Well, you'll get my ok in the sense of this looks good and better than
> nothing, but I'd really prefer a real fixup for this issues. Also the
> code above looks a bit unreadable, why not:
I guess I tend to prefer a real fixup too, if possible; I suppose
there's existing infrastructure to check it as a btree inode, and
hopefully to move it into extents as well.
FWIW I just copied the check above from xfs_check ;)
Sure, below formatting is better.
thanks,
-Eric
> 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, forkname, *nex);
> return 1;
> }
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-07-15 13:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-11 5:17 [PATCH, RFC] xfs_repair - clear inodes in incorrect btree format Eric Sandeen
2009-07-13 9:33 ` Olaf Weber
2009-07-13 14:34 ` Eric Sandeen
2009-07-15 13:07 ` Christoph Hellwig
2009-07-15 13:56 ` Eric Sandeen [this message]
-- 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=4A5DE008.5040103@sandeen.net \
--to=sandeen@sandeen.net \
--cc=hch@infradead.org \
--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