Re: [PATCH 09/10] xfs_repair: add a testing hook for NEEDSREPAIR

On 2/9/21 1:59 PM, Darrick J. Wong wrote:

quoted

# ./repair/xfs_repair -c needsrepair=1 /dev/test/scratch 
Phase 1 - find and verify superblock...
Marking filesystem in need of repair.
writing modified primary superblock
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
...
# mount /dev/test/scratch /mnt/
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/test-scratch, missing codepage or helper program, or other error.
#

It looks like we can set a feature upgrade bit on the superblock before
we've examined the log and potentially discovered that it's dirty (phase
2). If the log is recoverable, that puts the user in a bit of a bind..

Heh, funny that I was thinking that the upgrades shouldn't really be
happening in phase 1 anyway--

I've (separately) started working on a patch to make it so that you can
add reflink and finobt to a filesystem.  Those upgrades require somewhat
more intensive checks of the filesystem (such as checking free space in
each AG), so I ended up dumping them into phase 2, since the xfs_mount
and buffer cache aren't fully initialized until after phase 1.

So, yeah, the upgrade code should move to phase2() after log zeroing and
before the AG scan.

Oh, whoops - 

based on this, I think that the prior patch
[PATCH 08/10] xfs_repair: allow setting the needsrepair flag
needs to be adjusted as well, right; we don't want to set it in phase 1
or we might set it then abort on a dirty log and the user is stuck.

So maybe I should merge up through 

[PATCH 07/10] xfs_repair: set NEEDSREPAIR when we deliberately corrupt directories

and hold off on the rest? Or should I just hold off on the series and let
you reassemble (again?)

(Am I right that the upgrade bits will need to be moved and the series resent?)

-Eric