Re: filesystem dead, xfs_repair won't help

Avi Kivity
2017-04-11T07:46:12Z

On 04/10/2017 06:35 PM, Brian Foster wrote:
> On Mon, Apr 10, 2017 at 12:42:33PM +0300, Avi Kivity wrote:
>> On 04/10/2017 12:23 PM, Avi Kivity wrote:
>>> Today my kernel complained that in memory metadata is corrupt and
>>> asked that I run xfs_repair. But xfs_repair doesn't like the
>>> superblock and isn't able to find a secondary superblock.
>>>
>>> Latest Fedora 25 kernel, new Intel NVMe drive (worked for a few weeks
>>> without issue).
>>>
>>> Anything I can do to recover the data?
> Well I can't explain why you have a checksum error, but what do you mean
> that xfs_repair doesn't like the superblock? Can you provide the
> xfs_repair output?
>
> It seems strange for xfs_repair to not find the superblock of a
> filesystem that can otherwise run log recovery up until it encounters
> the buffer with a bad crc.

Sorry, should have done it earlier.

$ sudo xfs_repair /dev/nvme0n1
Phase 1 - find and verify superblock...
couldn't verify primary superblock - not enough secondary superblocks
with matching geometry !!!

attempting to find secondary superblock...
...........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................^C

In a previous run, after returning from lunch, xfs_repair did not find
the secondary superblock.

The superblock is there though:

$ sudo file -s /dev/nvme0n1
/dev/nvme0n1: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)

I can provide it if it will help.

>
> It also might be useful to find out exactly what that error reported by
> smartctl means. Are you aware of whether it pre-existed the filesystem
> issue or not?

I believe I ran it before and did not notice the error. I deal with
many disks, though, so it could have been that I just didn't notice it,
or that I ran it on a different machine.

>
>> Error Information (NVMe Log 0x01, max 64 entries)
>> Num ErrCount SQId CmdId Status PELoc LBA NSID VS
>> 0 1 1 0x0000 0x0286 - 0 1 -
>>
>>

If CmdId is the opcode, then it's a flush (matches the fact that LBA=0),
but I'm guessing it's the tag. 0x0286 is NVME_SC_ACCESS_DENIED, which
doesn't appear to match, though (if I picked the right enum).