On 11/16/20 3:13 PM, Darrick J. Wong wrote: > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > Enable users to upgrade their filesystems to support inode btree block > counters. > > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > --- > v2: set inprogress to force repair (which xfs_admin immediately does), > clean up the code to pass around fewer arguments, and try to revert the > change if we hit io errors > --- sooooo the inprogress thing sets off some unexpected behavior. In testing this, I noticed that if we have inprogress set, and uknown features/ version on disk, we go looking for backup superblocks and actually end up corrupting the filesystem before bailing out: # xfs_repair /dev/pmem0p2 Phase 1 - find and verify superblock... bad primary superblock - filesystem mkfs-in-progress bit set !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... writing modified primary superblock sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap inode pointer to 129 sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary inode pointer to 130 Superblock has unknown compat/rocompat/incompat features (0x0/0x8/0x0). Using a more recent xfs_repair is recommended. Found unsupported filesystem features. Exiting now. # xfs_db -c check /dev/pmem0p2 disconnected inode 129, nlink 1 disconnected inode 130, nlink 1 so this seems to have exposed a hole in how repair deals with unknown features when the inprogress bit is set. And TBH scampering off to find backup superblocks to "repair" an inprogress filesystem seems like ... not the right thing to do after a feature upgrade. I'm not sure what's better, but > bad primary superblock - filesystem mkfs-in-progress bit set !!! seems ... unexpected for this purpose. -Eric
