Hello,
so I've been crash-testing XFS (just killing KVM with XFS filesystem
mounted) a bit with V5 superblock enabled in 3.16-rc1 and I can pretty
easily hit CRC mismatches after that. Kernel complains like:
[518184.794175] XFS (sdb3): Mounting V5 Filesystem
[518184.902898] XFS (sdb3): Starting recovery (logdev: internal)
[518187.118860] XFS (sdb3): Metadata CRC error detected at xfs_agf_read_verify+0x5a/0x100 [xfs], block 0x1
[518187.118870] XFS (sdb3): Unmount and run xfs_repair
[518187.118875] XFS (sdb3): First 64 bytes of corrupted metadata buffer:
[518187.118882] ffff880136ffd600: 58 41 47 46 00 00 00 01 00 00 00 00 00 0f aa 40 XAGF...........@
[518187.118887] ffff880136ffd610: 00 02 6d 53 00 02 77 f8 00 00 00 00 00 00 00 01 ..mS..w.........
[518187.118891] ffff880136ffd620: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 03 ................
[518187.118895] ffff880136ffd630: 00 00 00 04 00 08 81 d0 00 08 81 a7 00 00 00 00 ................
[518187.118923] XFS (sdb3): metadata I/O error: block 0x1 ("xfs_trans_read_buf_map") error 74 numblks 1
So it seem like the checksum doesn't get updated properly in all the cases.
Looking into the logdump, there doesn't seem to be any modifications for
this AGF block in unrelayed part of the log but there are some modifications
in the older parts of the log - the latest LSN where block 1 was updated is
1,4639 (and the buffer contents in the log corresponds to the data I see in
block 1). However the lsn field in AGF structure in that block shows 1,3616
so that really seems stale (and I've checked and in that transaction the
block has been modified as well).
I'm looking into how the mismatch could happen but if anybody more
knowledgeable wants to have a look I have an unmodified fs image available
(however it has ~20G so if there's a way to make that smaller it would be
good).
Honza
--
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
