From: Luis Chamberlain <mcgrof@kernel.org>
To: kdevops@lists.linux.dev
Cc: linux-xfs@vger.kernel.org, Luis Chamberlain <mcgrof@kernel.org>
Subject: [PATCH kdevops] xfs: add xfs/242 as failing on xfs_reflink_2k
Date: Tue, 16 Apr 2024 16:51:08 -0700 [thread overview]
Message-ID: <20240416235108.3391394-1-mcgrof@kernel.org> (raw)
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@kernel.org>
---
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
next reply other threads:[~2024-04-16 23:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-16 23:51 Luis Chamberlain [this message]
2024-04-17 0:37 ` [PATCH kdevops] xfs: add xfs/242 as failing on xfs_reflink_2k Darrick J. Wong
2024-04-17 1:51 ` Luis Chamberlain
2024-04-17 4:48 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240416235108.3391394-1-mcgrof@kernel.org \
--to=mcgrof@kernel.org \
--cc=kdevops@lists.linux.dev \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.