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@xxxxxx/ > > 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@xxxxxx> > --- > 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 > >
