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 2/6] xfs_repair: enforce that inode btree chunks can't point to AG headers
Date: Thu, 30 Jan 2020 14:46:40 -0600 [thread overview]
Message-ID: <aa80935f-7f52-e559-8cb5-6800fe61b9f8@sandeen.net> (raw)
In-Reply-To: <20200130202600.GE3447196@magnolia>
On 1/30/20 2:26 PM, Darrick J. Wong wrote:
> On Thu, Jan 30, 2020 at 01:38:52PM -0600, Eric Sandeen wrote:
>> On 1/23/20 6:17 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.
>>
>> I peered back into the mists of time to see if I could find any reason for
>> this exception, and I couldn't.
>>
>> Only question is why you removed the
>>
>> - ASSERT(M_IGEO(mp)->ialloc_blks > 0);
>>
>> assert, that's still a valid assert, no?
>
> The superblock validation routines are supposed to reject all the
> combinations that can result in ialloc_blks being zero.
>
> That said, I can't think of a reason to remove the assert. If you want
> me to put it back, it I can... or pretty-please put it back in for me?
> :)
Sure, I'll try to remember to do that with your blessing.
It just didn't seem related to the rest of the patch, is all. If it's only
there to protect the next calculations, and this is a spot that makes no
sense to test it, I'm ok with dropping it too. Was just looking for a reason.
-Eric
next prev parent reply other threads:[~2020-01-30 20:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-24 0:17 [PATCH v3 0/6] xfs_repair: do not trash valid root dirs Darrick J. Wong
2020-01-24 0:17 ` [PATCH 1/6] mkfs: check root inode location Darrick J. Wong
2020-01-30 19:32 ` Eric Sandeen
2020-01-30 20:19 ` Darrick J. Wong
2020-01-30 20:34 ` Eric Sandeen
2020-01-24 0:17 ` [PATCH 2/6] xfs_repair: enforce that inode btree chunks can't point to AG headers Darrick J. Wong
2020-01-30 19:38 ` Eric Sandeen
2020-01-30 20:26 ` Darrick J. Wong
2020-01-30 20:46 ` Eric Sandeen [this message]
2020-01-24 0:17 ` [PATCH 3/6] xfs_repair: refactor fixed inode location checks Darrick J. Wong
2020-01-30 19:45 ` Eric Sandeen
2020-01-30 19:52 ` Eric Sandeen
2020-01-24 0:17 ` [PATCH 4/6] xfs_repair: use libxfs function to calculate root inode location Darrick J. Wong
2020-01-30 19:48 ` Eric Sandeen
2020-01-24 0:17 ` [PATCH 5/6] xfs_repair: check plausibility of root dir pointer before trashing it Darrick J. Wong
2020-01-30 20:18 ` Eric Sandeen
2020-01-30 20:34 ` Darrick J. Wong
2020-01-30 20:41 ` Eric Sandeen
2020-01-30 20:50 ` Darrick J. Wong
2020-01-24 0:18 ` [PATCH 6/6] xfs_repair: try to correct sb_unit value from secondaries Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
2020-01-01 1:20 [PATCH v2 0/6] xfs_repair: do not trash valid root dirs Darrick J. Wong
2020-01-01 1:20 ` [PATCH 2/6] xfs_repair: enforce that inode btree chunks can't point to AG headers 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=aa80935f-7f52-e559-8cb5-6800fe61b9f8@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