public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH, RFC] xfs_repair - clear inodes in incorrect btree format
Date: Wed, 15 Jul 2009 09:07:05 -0400	[thread overview]
Message-ID: <20090715130705.GA27973@infradead.org> (raw)
In-Reply-To: <4A582070.9040907@sandeen.net>

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.

> 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.

> +	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:


	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

  parent reply	other threads:[~2009-07-15 13:06 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 [this message]
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=20090715130705.GA27973@infradead.org \
    --to=hch@infradead.org \
    --cc=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