On 2/9/21 1:59 PM, Darrick J. Wong wrote: >> # ./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
