All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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 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.