This test is rather simple, and somehow we managed to capture a
non-crash failure. The test was added to fstests via fstests commit
0c95fadc35c8e450 ("expand 252 with more corner case tests") which
essentially does this:
+ $XFS_IO_PROG $xfs_io_opt -f -c "truncate $block_size" \
+ -c "pwrite 0 $block_size" $sync_cmd \
+ -c "$zero_cmd 128 128" \
+ -c "$map_cmd -v" $testfile | $filter_cmd
The map_cmd in this case is: 'bmap -p'. So the test does:
a) truncates data to the block size
b) sync
c) zero-fills the the blocksize
The xfs_io bmap displays the block mapping for the current open file.
Since our failed delta is:
-0: [0..7]: data
+0: [0..7]: unwritten
So it would seem we somehow managed to race to write, but it never
went anywhere. I can't reproduce yet, but figured I'd put this out
there to at least acknowledge its seen at least once.
Signed-off-by: Luis Chamberlain <mcgrof@xxxxxxxxxx>
---
Super rare to trigger this but figured I'd check to see if others have seen
this fail before. This was on vanilla v6.8-rc2. I'm wondering a race is
possible with a guest using sparse files on the host, and the host somehow
incorrectly informing the guest the write is done. btrfs sparse files
were used on the host for the drives used by this guest for scratch drives.
.../fstests/expunges/6.8.0-rc2/xfs/unassigned/xfs_reflink_2k.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/workflows/fstests/expunges/6.8.0-rc2/xfs/unassigned/xfs_reflink_2k.txt b/workflows/fstests/expunges/6.8.0-rc2/xfs/unassigned/xfs_reflink_2k.txt
index f6ea47b0479f..8b4161f3700e 100644
--- a/workflows/fstests/expunges/6.8.0-rc2/xfs/unassigned/xfs_reflink_2k.txt
+++ b/workflows/fstests/expunges/6.8.0-rc2/xfs/unassigned/xfs_reflink_2k.txt
@@ -19,6 +19,7 @@ xfs/075
xfs/155
xfs/168
xfs/188
+xfs/242 # F:1/2000 non-fatal failure cosmic ray? https://gist.github.com/mcgrof/6ef50311179a65221413a63c0cc8efd1
xfs/270
xfs/301
xfs/502 # F:1/8 korg#218226 xfs assert fs/xfs/xfs_message.c:102
--
2.43.0
