Re: filesystem dead, xfs_repair won't help

Eric Sandeen
2017-04-11T16:48:20Z

On 4/11/17 11:44 AM, Avi Kivity wrote:
>
>
> On 04/11/2017 07:13 PM, Emmanuel Florac wrote:
>> Le Tue, 11 Apr 2017 16:07:56 +0300
>> Avi Kivity <avi@scylladb.com> écrivait:
>>
>>> $ sudo xfs_db -c 'sb 0' -c 'check' /tmp/fsimage
>>> ERROR: The filesystem has valuable metadata changes in a log which
>>> needs to be replayed. Mount the filesystem to replay the log, and
>>> unmount it before re-running xfs_db. If you are unable to mount the
>>> filesystem, then use the xfs_repair -L option to destroy the log and
>>> attempt a repair. Note that destroying the log may cause corruption
>>> -- please attempt a mount of the filesystem before doing this.
>>>
>>>
>>> xfs_repair did not recognize the superblock, and started hunting for
>>> the second one, emitting dots in the process. I stopped it, since it
>>> failed on the live disk.
>>>
>> Can you mount the image, or does it fail immmediately because of the
>> CRC error?
>>
>
> Fails immediately.
>
> I'll probably format it with ext4, wait for the firmware update, and
> then reformat it with xfs. Since the firmware bug was acknowledged, I
> don't know what we can gain from it. My disk is mostly a git and imap
> mirror anyway, + a large ccache repository, + a throwaway database.

Honestly, I'd be a little leary of ext4 too - I don't know what the underlying
problem is, but it must be related to some IO pattern that is more common
on xfs, but it's a leap to say that it's never present on any other fs...

IOWS: a drive firmware bug that corrupts data probably can't be trusted
with any filesystem.

As an experiment, though, if you want to play, it might be interesting to
mkfs.xfs it with a 4096 byte sector size, and see if that makes it happier.
By default, xfs is doing metadata IO in 512 chunks, something other filesystems
won't do by default.

I guess you don't know how to provoke the corruption, though, to be able
to run that test reliably...

-Eric