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).
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
