On 2/12/24 3:06 PM, Dave Chinner wrote: > That has the XFS_SB_FEAT_INCOMPAT_NEEDSREPAIR bit set... > >> I wonder if that is because I tried a xfs_repair with a newer version... > .... which is a result of xfs_repair 6.5.0 crashing mid way through > repair of the filesystem. Your kernel is too old to recognise the > NEEDSREPAIR bit. You can clear it with xfs_db like this: > > Run this to get the current field value: > > # xfs_db -c "sb 0" -c "p features_incompat" <dev> > > Then subtract 0x10 from the value returned and run: > > # xfs_db -c "sb 0" -c "write features_incompat <val>" <dev> > > But that won't get you too far - the filesystem is still corrupt and > inconsistent. By blowing away the log with xfs_repair before > actually determining if the problem was caused by a RAID array > issue, you've essentially forced yourself into a filesystem recovery > situation. Everything Dave said, yes. Depending on how bad the corruption is, you *might* be able to do a readonly or readonly/norecovery mount and scrape some data out. Ideally the first thing to do would be to make a 1:1 dd image of the device as a safe backup, but I understand it's 300T ... -Eric
