From: Eric Sandeen <sandeen@sandeen.net>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
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:40:36 -0800 [thread overview]
Message-ID: <52f6c291-2826-c74f-6283-a6d4d643dfc5@sandeen.net> (raw)
In-Reply-To: <20200226173236.GG8045@magnolia>
On 2/26/20 9:32 AM, Darrick J. Wong wrote:
> 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?
nah I made my peace with that ;)
> 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?
Good grief I sent this reply on the wrong patch, the discussion was on
"check plausibility of root dir pointer before trashing it"
me--
> 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.
Ah ok, got it. Let me go ask a question in reply to that.
Sorry for the confusion.
Thanks,
-Eric
next prev parent reply other threads:[~2020-02-26 17:40 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
2020-02-26 17:40 ` Eric Sandeen [this message]
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=52f6c291-2826-c74f-6283-a6d4d643dfc5@sandeen.net \
--to=sandeen@sandeen.net \
--cc=alex@zadara.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
/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).