public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Boris Burkov <boris@bur.io>
Cc: kernel-team@fb.com, fstests@vger.kernel.org,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH RFC] generic/730: ensure EIO after device delete
Date: Thu, 14 Mar 2024 19:56:28 -0700	[thread overview]
Message-ID: <20240315025628.GH6188@frogsfrogsfrogs> (raw)
In-Reply-To: <6165b0018426e58e7427a26eebea3d63e66fed15.1710373423.git.boris@bur.io>

On Wed, Mar 13, 2024 at 04:47:47PM -0700, Boris Burkov wrote:
> 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.

Does btrfs prefetch pagecache data as soon as a file opens?  Or I guess
it could be that xfs trips an IO error and shuts down, and
xfs_file_read_iter will return EIO after that happens.

--D

> 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-15  2:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-13 23:47 [PATCH RFC] generic/730: ensure EIO after device delete Boris Burkov
2024-03-15  2:56 ` Darrick J. Wong [this message]
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=20240315025628.GH6188@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=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