From: Boris Burkov <boris@bur.io>
To: kernel-team@fb.com, fstests@vger.kernel.org
Cc: Christoph Hellwig <hch@lst.de>
Subject: [PATCH RFC] generic/730: ensure EIO after device delete
Date: Wed, 13 Mar 2024 16:47:47 -0700 [thread overview]
Message-ID: <6165b0018426e58e7427a26eebea3d63e66fed15.1710373423.git.boris@bur.io> (raw)
This test removes a SCSI debug device out from under a mounted
filesystem with a (probably) dirty file. This assumes that page cache
cannot save us from EIO, for a reason that I can't quite explain. In
fact, this test fails for exactly that reason, at least on btrfs.
The original patches:
https://lore.kernel.org/fstests/20230807112100.GB15405@lst.de/
refer to this passing on xfs and not btrfs, so I suspect I am missing
something. With that said, on my machine this actually fails on xfs with
and without my patch, so this is clearly not enough.
High level, I am trying to understand what is really the expected
behavior from a filesystem under this condition and what this test is
getting at. Of btrfs, ext4, and xfs, only ext4 passes it, while btrfs
does pass with this additional syncing/cache dropping to nudge it to an
error.
Signed-off-by: Boris Burkov <boris@bur.io>
---
tests/generic/730 | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/generic/730 b/tests/generic/730
index 11308cdaa..ca5037c57 100755
--- a/tests/generic/730
+++ b/tests/generic/730
@@ -47,6 +47,9 @@ exec 3< $SCSI_DEBUG_MNT/testfile
# delete the scsi debug device while it still has dirty data
echo 1 > /sys/block/$(_short_dev $SCSI_DEBUG_DEV)/device/delete
+sync
+echo 3 > /proc/sys/vm/drop_caches
+
# try to read from the file, which should give us -EIO
cat <&3 > /dev/null
--
2.43.0
next reply other threads:[~2024-03-13 23:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-13 23:47 Boris Burkov [this message]
2024-03-15 2:56 ` [PATCH RFC] generic/730: ensure EIO after device delete Darrick J. Wong
2024-03-15 23:30 ` Boris Burkov
2024-03-16 13:08 ` Filipe Manana
2024-03-16 14:40 ` Boris Burkov
2024-03-16 17:42 ` Filipe Manana
2024-03-17 20:38 ` Christoph Hellwig
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=6165b0018426e58e7427a26eebea3d63e66fed15.1710373423.git.boris@bur.io \
--to=boris@bur.io \
--cc=fstests@vger.kernel.org \
--cc=hch@lst.de \
--cc=kernel-team@fb.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).