Re: Metadata corruption detected, fatal error -- couldn't map inode, err = 117

[Dave Chinner <david@fromorbit.com>]

On Thu, Dec 21, 2023 at 08:05:43PM -0600, Phillip Ferentinos wrote:
> Hello,
> 
> Looking for opinions on recovering a filesystem that does not
> successfully repair from xfs_repair.

What version of xfs_repair?

> On the first xfs_repair, I was
> prompted to mount the disk to replay the log which I did successfully.
> I created an image of the disk with ddrescue and am attempting to
> recover the data. Unfortunately, I do not have a recent backup of this
> disk.

There is lots of random damage all over the filesystem. What caused
this damage to occur? I generally only see this sort of widespread
damage when RAID devices (hardware or software) go bad...

Keep in mind that regardless of whether xfs_repair returns the
filesystem to a consistent state, the data in the filesystem is
still going to be badly corrupted. If you don't have backups, then
there's a high probability of significant data loss here....

> The final output of xfs_repair is:
> 
> Phase 5 - rebuild AG headers and trees...
>         - reset superblock...
> Phase 6 - check inode connectivity...
>         - resetting contents of realtime bitmap and summary inodes
>         - traversing filesystem ...
> rebuilding directory inode 12955326179
> Metadata corruption detected at 0x46fa05, inode 0x38983bd88 dinode

Can you run 'gdb xfs_repair' and run the command 'l *0x46fa05' to
dump the line of code that the error was detected at? You probably
need the distro debug package for xfsprogs installed to do this.

> fatal error -- couldn't map inode 15192014216, err = 117
> 
> The full log is:
> https://raw.githubusercontent.com/phillipjf/xfs_debug/main/xfs_repair_1.log

That's messy.

> Based on another discussion (https://narkive.com/4dDxIees.10), I've
> included the specific inode:
> https://raw.githubusercontent.com/phillipjf/xfs_debug/main/xfs_db_01.log

Nothing obviously wrong with that inode in the image file - it's a
directory inode in node format that looks to be internally
consistent.  But that inode has been processed earlier in the repair
process, so maybe it's bad in memory as a result of trying to fix
some other problem. Very hard to say given how much other stuff is
broken and is getting either trashed, re-initialised or repaired up
to that point....

> I also cannot create a metadump due to the following issue:
> https://raw.githubusercontent.com/phillipjf/xfs_debug/main/xfs_metadump_01.log.

No surprise, metadump has to traverse the metadata in order to dump
it, and if the metadata is corrupt then the traversals can fail
leading to a failed dump. The more badly damaged the filesystem is,
the more likely a metadump failure is.

-Dave.
-- 
Dave Chinner
david@fromorbit.com