Fix race in the mmap test

The mmap test kicks off a background xfs_io job, then does a
scoutfs stage operation in the foreground and sleeps for one
second. Usually that's enough time for the background job to
complete, but very rarely it's not.

This manifests as data corruption when we try to read too soon.
But we can also see from the jobs command output that there's
still a job running.

Use an explicit wait instead of the "sleep 1".

Signed-off-by: Chris Kirby <ckirby@versity.com>
This commit is contained in:
Chris Kirby
2026-07-18 13:07:12 -05:00
parent a07327d8a6
commit 4916b761e1
2 changed files with 2 additions and 8 deletions
-2
View File
@@ -10,14 +10,12 @@ thread 4 complete
extents: 1
1
00000200: ea ea ea ea ea ea ea ea ea ea ea ea ea ea ea ea ................
0
0: offset: 0 length: 2 flags: ..L
extents: 1
== mmap write to an offline extent
0: offset: 0 length: 2 flags: O.L
extents: 1
1
0
0: offset: 0 length: 2 flags: ..L
extents: 1
00000000 ea ea ea ea ea ea ea ea ea ea ea ea ea ea ea ea |................|
+2 -6
View File
@@ -27,9 +27,7 @@ sleep 1
jobs | wc -l
scoutfs stage "${F}-stage" "$F" -V "$vers" -o 0 -l 8192
# xfs_io thread <here> will output 16 bytes of read data
sleep 1
# should be 0 - no more waiting jobs, xfs_io should have exited
jobs | wc -l
wait
scoutfs get-fiemap -L "$F"
echo "== mmap write to an offline extent"
@@ -43,9 +41,7 @@ sleep 1
jobs | wc -l
scoutfs stage "${F}-stage" "$F" -V "$vers" -o 0 -l 8192
# no output here from write
sleep 1
# should be 0 - no more waiting jobs, xfs_io should have exited
jobs | wc -l
wait
scoutfs get-fiemap -L "$F"
# read back contents to assure write changed the file
dd status=none if="$F" bs=1 count=48 skip=512 | hexdump -C