linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: linux-xfs@vger.kernel.org, alex@zadara.com
Subject: Re: [PATCH 3/7] xfs_repair: enforce that inode btree chunks can't point to AG headers
Date: Wed, 26 Feb 2020 09:32:36 -0800	[thread overview]
Message-ID: <20200226173236.GG8045@magnolia> (raw)
In-Reply-To: <402fd276-109a-3f46-8b9f-68bcf836c001@sandeen.net>

On Wed, Feb 26, 2020 at 09:19:53AM -0800, Eric Sandeen wrote:
> On 2/4/20 4:46 PM, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > xfs_repair has a very old check that evidently excuses the AG 0 inode
> > btrees pointing to blocks that are already marked XR_E_INUSE_FS* (e.g.
> > AG headers).  mkfs never formats filesystems that way and it looks like
> > an error, so purge the check.  After this, we always complain if inodes
> > overlap with AG headers because that should never happen.
> 
> On a previous version, you and Brian had a fairly long conversation about
> the warning this presents, and how it doesn't tell the user what to do
> about it, and how the warning will persist, and may generate bug reports
> or questions.
> 
> It sounded like you had a plan to address that, which does not seem to be
> present in this patch? So I'm not sure Brian's concerns have been resolved
> yet.

I'm confused about "the warning this presents" -- are you talking about
this patch specifically, where we couldn't figure out the weird masking
behavior that dated back to 2001 and the hysterical raisins?

Or are you referring to Brian's criticism of earlier versions of this
series that would whine about our root inode computation not leading to
the root inode without actually telling the user what to do about it?

If it's the second, then I the answer is that I added another patch
("xfs_repair: try to correct sb_unit value from secondaries") to try to
recover a working sunit value from the backup superblocks, or try some
power of two guesses to see if we find one that matches, and then reset
the value to something that will make the computation work again.

--D

> 
> -Eric

  reply	other threads:[~2020-02-26 17:32 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-05  0:46 [PATCH v4 0/7] xfs_repair: do not trash valid root dirs Darrick J. Wong
2020-02-05  0:46 ` [PATCH 1/7] xfs_repair: replace verify_inum with libxfs inode validators Darrick J. Wong
2020-02-05  0:50   ` Darrick J. Wong
2020-02-17 13:50   ` Christoph Hellwig
2020-02-19  4:32     ` Darrick J. Wong
2020-02-26 16:55   ` Eric Sandeen
2020-02-05  0:46 ` [PATCH 2/7] mkfs: check root inode location Darrick J. Wong
2020-02-17 13:50   ` Christoph Hellwig
2020-02-05  0:46 ` [PATCH 3/7] xfs_repair: enforce that inode btree chunks can't point to AG headers Darrick J. Wong
2020-02-17 13:51   ` Christoph Hellwig
2020-02-26 17:09   ` Eric Sandeen
2020-02-26 17:24     ` Darrick J. Wong
2020-02-26 17:34       ` Eric Sandeen
2020-02-26 17:19   ` Eric Sandeen
2020-02-26 17:32     ` Darrick J. Wong [this message]
2020-02-26 17:40       ` Eric Sandeen
2020-02-05  0:47 ` [PATCH 4/7] xfs_repair: refactor fixed inode location checks Darrick J. Wong
2020-02-17 13:51   ` Christoph Hellwig
2020-02-05  0:47 ` [PATCH 5/7] xfs_repair: use libxfs function to calculate root inode location Darrick J. Wong
2020-02-17 13:53   ` Christoph Hellwig
2020-02-05  0:47 ` [PATCH 6/7] xfs_repair: check plausibility of root dir pointer before trashing it Darrick J. Wong
2020-02-17 13:53   ` Christoph Hellwig
2020-02-05  0:47 ` [PATCH 7/7] xfs_repair: try to correct sb_unit value from secondaries Darrick J. Wong
2020-02-17 13:55   ` Christoph Hellwig
2020-02-26 17:42   ` Eric Sandeen
2020-02-26 17:55     ` Darrick J. Wong

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=20200226173236.GG8045@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=alex@zadara.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /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;
as well as URLs for NNTP newsgroup(s).