Description of problem: I hit a XFS corruption several times on ppc64le, by running generic/299 on 2k blocksize XFS (reflink=1,rmapbt=1): # # FSQA Test No. 299 # # AIO/DIO stress test # Run random AIO/DIO activity and fallocate/truncate simultaneously # Test will operate on huge sparsed files so ENOSPC is expected. # FSTYP -- xfs (non-debug) PLATFORM -- Linux/ppc64le xxxxxxx 4.20.0-rc1.kasan MKFS_OPTIONS -- -f -b size=2048 -m crc=1,finobt=1,reflink=1,rmapbt=1 -i sparse=1 /dev/vda5 MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/vda5 /mnt/xfstests/mnt2 generic/299 176s ... _check_xfs_filesystem: filesystem on /dev/vda5 is inconsistent (r) (see /var/lib/xfstests/results//generic/299.full for details) Ran: generic/299 Failures: generic/299 Failed 1 of 1 tests Version-Release number of selected component (if applicable): https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git xfs-4.20-fixes-2 How reproducible: 1~2% on my ppc64le kvm machine. But it's hard to reproduce on my x86_64 real machine. Steps to Reproduce: Loop running generic/299, but maybe not easy to hit it Actual results: XFS corruption Expected results: test always pass Additional info: Please check the full output and xfs metadump from attachments.
Created attachment 279661 [details] corrupted xfs metadump file
Created attachment 279663 [details] generic/299.full
I've tried current upstream xfsprogs for-next branch, which HEAD is: commit caa91046eee63f10635acefd559cdfb56e9e214e (HEAD -> for-next, tag: v4.19.0, origin/master, origin/for-next, origin/HEAD, master) Author: Eric Sandeen <sandeen@sandeen.net> Date: Fri Nov 9 14:31:04 2018 -0600 xfsprogs: Release v4.19.0 xfs_repair still report this corruption.