On Sun, Feb 11, 2024 at 12:39 PM Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > I was going to suggest creating an xfs_metadump image for analysis. > Was that created with xfsprogs v6.5.0 as well? > so the metadump did not complete? I actually tried running xfs_metadump with both v5.0 and v6.5.0. They both gave many error messages, but they created files. Not sure what I can do with those files > Does the filesystem mount? Can you mount it -o ro or -o ro,norecovery > to see how much you can read off of it? The file system doesn't mount. the message when I try to mount it is: mount: /data: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error. and Feb 12 10:06:02 hgdownload1 kernel: XFS (sda1): Superblock has unknown incompatible features (0x10) enabled. Feb 12 10:06:02 hgdownload1 kernel: XFS (sda1): Filesystem cannot be safely mounted by this kernel. Feb 12 10:06:02 hgdownload1 kernel: XFS (sda1): SB validate failed with error -22. I wonder if that is because I tried a xfs_repair with a newer version... > > If mount fails, what is in the kernel log when it fails? > Power losses really should not cause corruption, it's a metadata journaling > filesytem which should maintain consistency even with a power loss. > > What kind of storage do you have, though? Corruption after a power loss often > stems from a filesystem on a RAID with a write cache that does not honor > data integrity commands and/or does not have its own battery backup. We have a RAID 6 card with a BBU: Product Name : AVAGO MegaRAID SAS 9361-8i Serial No : SK00485396 FW Package Build: 24.21.0-0017 I agree that power issues should not cause corruption, but here we are. Somewhere on one of the discussion threads I saw somebody mention ufsexplorer, and when I downloaded the trial version, it seemed to see most of the files on the device. I guess if I can't find a way to recover the current filesystem, I will try to use that to recover the data.
