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@xxxxxxxxxxxx> é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 -- 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
