Here’s the xfs_metadump (1.35 GB) : https://dl.plik.ovh/file/kyXGCIy5luJe7ZKi/ZvUMwvCqUVPiQ2Oe/sdb.metadump.xz Julien > On 21 Jan 2019, at 17:42, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > > > > On 1/21/19 9:36 AM, Julien Lutran wrote: >> Hello, >> >> I’m experiencing an issue with metadata corruption while trying to fix several corrupted xfs filesystems. >> Here’s an excerpt of the kernel messages when the disk is mounted : >> >> […] >> Jan 21 15:44:16 rescue kernel: XFS (sdb): Metadata corruption detected at xfs_inode_buf_verify+0x6d/0xf0, xfs_inode block 0x300160 >> Jan 21 15:44:16 rescue kernel: XFS (sdb): Unmount and run xfs_repair >> Jan 21 15:44:16 rescue kernel: XFS (sdb): First 64 bytes of corrupted metadata buffer: >> Jan 21 15:44:16 rescue kernel: XFS (sdb): metadata I/O error: block 0x300160 ("xfs_trans_read_buf_map") error 117 numblks 16 >> Jan 21 15:44:16 rescue kernel: XFS (sdb): xfs_imap_to_bp: xfs_trans_read_buf() returned error -117. >> >> I tried to run a xfs_repair (see attached log) but it ends up the same way : metadata error on block 0x300160 >> Is there a way to fix this corruption ? >> >> Linux kernel version is 4.14.17 but I encountered the exact same issue in several other hosts running an older kernel. >> Xfsprogs version is 4.19.0 >> >> >> Best regards, >> Julien Lutran > > Hi Julien - > > Your log file says: > > "Start xfs_repair with cmdline: xfs_repair -L -m 8047 /dev/sdb" > > 1) Why did you use -L, would the log not replay? > 2) Why use -m? Does that affect the outcome at all? > 3) You could give the for-next branch in git a try, just in case, but otherwise > 4) Please provide a compressed xfs_metadump for me to look at, off list, and > I'll see what I can find. > > Thanks, > -Eric
Attachment:
signature.asc
Description: Message signed with OpenPGP
