On Wed, Feb 26, 2020 at 09:42:01AM -0800, Eric Sandeen wrote:
> On 2/4/20 4:47 PM, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> >
> > If the primary superblock's sb_unit leads to a rootino calculation that
> > doesn't match sb_rootino /but/ we can find a secondary superblock whose
> > sb_unit does match, fix the primary.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> > ---
>
> With the previous patch issuing a warning
>
> +_("sb root inode value %" PRIu64 " valid but in unaligned location (expected %"PRIu64") possibly due to sunit change\n"),
>
> What does this do in the case where the user intentionally changed the
> sunit, which is (I think) the situation launched this work in the first
> place?
[echoing what we just discussed on irc]
repair will print the above warning, and then it'll try to find either a
backup sb with a sunit value that makes the computation work, or guess
at sunit values until it finds one that makes the computation work. If
it finds a reasonable sunit value it'll change it back to that.
If the user mounts an old kernel with the same bad sunit value, the
kernel will set it back to the bad value and we wash, rinse, and repeat.
If the user mounts a new kernel with the same bad sunit value, it'll
decline to change the sunit value.
If the user runs the bad-sunit fs against an old xfs_repair it will
descend into madness nuking the root directory, which is why we're
trying to nudge ourselves away from the bad value.
> Will that warning persist in the case of an intentional sunit change?
Yes.
--D
> Thanks,
> -Eric
>
