On 6/23/23 3:25 PM, Fernando CMK wrote:
Scenario
opensuse 15.5, the fs was originally created on an earlier opensuse
release. The failed file system is on top of a mdadm raid 5, where
other xfs file systems were also created, but only this one is having
issues. The others are doing fine.
xfs_repair and xfs_repair -L both fail:
Full logs please, not the truncated version.
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
- 16:15:34: verify and correct link counts - 42 of 42
allocation groups done
stripe width (17591899783168) is too large
Metadata corruption detected at 0x55f819658468, xfs_sb block 0x0/0x1000
libxfs_bwrite: write verifier failed on xfs_sb bno 0x0/0x8
stripe width (17591899783168) is too large
0xFFFEEF00000 - that's suspicious. No idea how the stripe unit could
have been set to something so big.
Metadata corruption detected at 0x55f819658468, xfs_sb block 0x0/0x1000
libxfs_bwrite: write verifier failed on xfs_sb bno 0x0/0x8
xfs_repair: Releasing dirty buffer to free list!
xfs_repair: Refusing to write a corrupt buffer to the data device!
xfs_repair: Lost a write to the data device!
fatal error -- File system metadata writeout failed, err=117. Re-run
xfs_repair.
I ran xfs_repair multiple times, but I always get the same error.
First, what version of xfs_repair are you using? xfs_Repair -V.
Latest is roughly the latest kernel, 6.x.
Is there any way to fix the above?
I tried xfs_db on an image file I created from the file system, and I
can see individual paths and file "good":
xfs_db> path /certainpath
xfs_db> ls
10 1550204032 directory 0x0000002e 1 . (good)
12 1024 directory 0x0000172e 2 .. (good)
25 1613125696 directory 0x99994f93 13 .AfterShotPro (good)
Is there a way to extract files from the file system image without
mounting the fs ? Or is there a way to mount the file system
regardless of its state?
mount -o ro,norecovery should get you something ...
Trying a regular mount, with or withour -o norecovery, I get:
mount: /mnt: mount(2) system call failed: Structure needs cleaning.
... oh. And what did the kernel dmesg say when that happened?
What happened in between this filesystem being ok, and not being ok?
What was the first sign of trouble?
If you want to provide an xfs_metadump (compressed, on gdrive or
something, you can email me off-list) I can take a look.
-Eric
Regards.
