Comment 8 for bug 1686687

Anonymous (anonymous654) wrote :

We did get around to do more testing and follow suggestions. The filesystem corruption could be reproduced. The run was done bypassing multipathing and using a single path directly.

OUTPUT reproduce.sh (tail):

+ fstrim -v /mnt/san
/mnt/san: 120 TiB (131939249291264 bytes) trimmed
+ umount -vvv /mnt/san
umount: /mnt/san unmounted
+ sync
+ mount -vvv
/dev/disk/by-path/pci-0000:02:00.0-fc-0x9999999999999999-lun-0 /mnt/san
mount: mount /dev/sde on /mnt/san failed: Structure needs cleaning
+ fail '3rd mount failed'
+ echo 'ERROR: 3rd mount failed'
ERROR: 3rd mount failed
+ exit 11

OUTPUT dmesg:

[13568.741492] XFS (sde): metadata I/O error: block 0x39fffffc70
("xfs_trans_read_buf_map") error 74 numblks 8 [13568.891639] XFS (sde): Metadata CRC error detected at
xfs_agi_read_verify+0x5e/0x110 [xfs], xfs_agi block 0x3a7ffffc68 [13569.033899] XFS (sde): Unmount and run xfs_repair [13569.103826] XFS (sde): First 64 bytes of corrupted metadata buffer:
[13569.174222] ffff9107a8836000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[13569.314629] ffff9107a8836010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[13569.454924] ffff9107a8836020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[13569.595204] ffff9107a8836030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

----

Since there is no fstab entry, mount options are determined by whatever mechanism decides on defaults. In this case, mount reported the following:

xfs (rw,relatime,attr2,inode64,noquota)

The kernel for this run:

$ uname -a
Linux xxxxxxx 4.11.0-041100rc8-generic #201704232131 SMP Mon Apr 24 01:32:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux