fstests.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Burkov <boris@bur.io>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com, fstests@vger.kernel.org
Subject: Re: [PATCH v2] generic: test fiemap offsets and < 512 byte ranges
Date: Wed, 7 Apr 2021 13:27:18 -0700	[thread overview]
Message-ID: <YG4VkCWy3BK2zwnr@zen> (raw)
In-Reply-To: <20210407161046.GY1670408@magnolia>

On Wed, Apr 07, 2021 at 09:10:46AM -0700, Darrick J. Wong wrote:
> On Tue, Apr 06, 2021 at 03:54:29PM -0700, Boris Burkov wrote:
> > btrfs trims fiemap extents to the inputted offset, which leads to
> > inconsistent results for most inputs, and downright bizarre outputs like
> > [7..6] when the trimmed extent is at the end of an extent and shorter
> > than 512 bytes.
> > 
> > This test covers a bunch of cases like that and ensures that file
> > systems always return the full extent without trimming it.
> > 
> > I also ran it under ext2, ext3, ext4, f2fs, and xfs successfully, but I
> > suppose it's no guarantee that every file system will store a 4k synced
> > write in a single extent. For that reason, this might be a bit fragile.
> 
> Does it work with 64k fs blocks?  Or 512b blocks? :)
> 

I don't have easy access to a means of testing with 64k blocks, but I
did test the more flexible v3 on 512, 1024, 2048, and 4096 byte blocks.

> Also... is there an xfs_io fix to go with this?
> 

Since the xfs_bmap manpage says that it outputs in 512 byte chunks and
the xfs_io manpage says fiemap should output the full extent, I figured
this was a case of garbage-in-garbage-out.

Do you think xfs_io fiemap should handle these <=512 byte cases more
permissively? With xfs and -b size=512, I got:
0: [0..0]: 11..11
which might really be a bug.

> > 
> > This test is fixed for btrfs by:
> > btrfs: return whole extents in fiemap
> > (https://lore.kernel.org/linux-btrfs/274e5bcebdb05a8969fc300b4802f33da2fbf218.1617746680.git.boris@bur.io/)
> > 
> > Signed-off-by: Boris Burkov <boris@bur.io>
> > 
> > --
> > v2: fill out copyright and test description
> > 
> > ---
> >  tests/generic/623     | 94 +++++++++++++++++++++++++++++++++++++++++++
> >  tests/generic/623.out |  2 +
> >  tests/generic/group   |  1 +
> >  3 files changed, 97 insertions(+)
> >  create mode 100755 tests/generic/623
> >  create mode 100644 tests/generic/623.out
> > 
> > diff --git a/tests/generic/623 b/tests/generic/623
> > new file mode 100755
> > index 00000000..85ef68f6
> > --- /dev/null
> > +++ b/tests/generic/623
> > @@ -0,0 +1,94 @@
> > +#! /bin/bash
> > +# SPDX-License-Identifier: GPL-2.0
> > +# Copyright (c) 2021 Facebook.  All Rights Reserved.
> > +#
> > +# FS QA Test 623
> > +#
> > +# Test fiemaps with offsets into small parts of extents.
> > +# Expect to get the whole extent, anyway.
> > +#
> > +seq=`basename $0`
> > +seqres=$RESULT_DIR/$seq
> > +echo "QA output created by $seq"
> > +
> > +here=`pwd`
> > +tmp=/tmp/$$
> > +status=1	# failure is the default!
> > +trap "_cleanup; exit \$status" 0 1 2 3 15
> > +
> > +_cleanup()
> > +{
> > +	cd /
> > +	rm -f $tmp.*
> > +}
> > +
> > +# get standard environment, filters and checks
> > +. ./common/rc
> > +. ./common/filter
> > +
> > +# remove previous $seqres.full before test
> > +rm -f $seqres.full
> > +
> > +# real QA test starts here
> > +
> > +# Modify as appropriate.
> > +_supported_fs generic
> > +_require_test
> > +_require_scratch
> > +_require_xfs_io_command "fiemap"
> > +
> > +rm -f $seqres.full
> > +
> > +_do_fiemap() {
> > +	off=$1
> > +	len=$2
> > +	$XFS_IO_PROG -c "fiemap $off $len" $SCRATCH_MNT/foo
> > +}
> > +
> > +_check_fiemap() {
> 
> Only helper functions in common/ need to be prefixed with "_".
> 
> > +	off=$1
> > +	len=$2
> > +	actual=$(_do_fiemap $off $len | tee -a $seqres.full)
> > +	[ "$actual" == "$expected" ] || _fail "unexpected fiemap on $off $len"
> > +}
> > +
> > +_scratch_mkfs >>$seqres.full 2>&1
> > +_scratch_mount
> 
> You could probably accomplish this by creating a file on the test
> device, which means this test would run on configurations where there's
> no scratch device; and run faster since there's no longer any need for
> mkfs.
> 
> --D
> 

Thanks for the review,
Boris

> > +
> > +# write a file with one extent
> > +$XFS_IO_PROG -f -s -c "pwrite -S 0xcf 0 4K" $SCRATCH_MNT/foo >/dev/null
> > +
> > +# since the exact extent location is unpredictable especially when
> > +# varying file systems, just test that they are all equal, which is
> > +# what we really expect.
> > +expected=$(_do_fiemap)
> > +
> > +# start to mid-extent
> > +_check_fiemap 0 2048
> > +# start to end
> > +_check_fiemap 0 4096
> > +# start to past-end
> > +_check_fiemap 0 4097
> > +# mid-extent to mid-extent
> > +_check_fiemap 1024 2048
> > +# mid-extent to end
> > +_check_fiemap 2048 4096
> > +# mid-extent to past-end
> > +_check_fiemap 2048 4097
> > +
> > +# to end; len < 512
> > +_check_fiemap 4091 5
> > +# to end; len == 512
> > +_check_fiemap 3584 512
> > +# past end; len < 512
> > +_check_fiemap 4091 500
> > +# past end; len == 512
> > +_check_fiemap 4091 512
> > +
> > +_scratch_unmount
> > +
> > +echo "Silence is golden"
> > +
> > +# success, all done
> > +status=0
> > +exit
> > diff --git a/tests/generic/623.out b/tests/generic/623.out
> > new file mode 100644
> > index 00000000..6f774f19
> > --- /dev/null
> > +++ b/tests/generic/623.out
> > @@ -0,0 +1,2 @@
> > +QA output created by 623
> > +Silence is golden
> > diff --git a/tests/generic/group b/tests/generic/group
> > index b10fdea4..39e02383 100644
> > --- a/tests/generic/group
> > +++ b/tests/generic/group
> > @@ -625,3 +625,4 @@
> >  620 auto mount quick
> >  621 auto quick encrypt
> >  622 auto shutdown metadata atime
> > +623 auto quick
> > -- 
> > 2.30.2
> > 

      parent reply	other threads:[~2021-04-07 20:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-06 22:47 [PATCH] generic: test fiemap offsets and < 512 byte ranges Boris Burkov
2021-04-06 22:54 ` [PATCH v2] " Boris Burkov
2021-04-07 16:10   ` Darrick J. Wong
2021-04-07 20:13     ` [PATCH v3] " Boris Burkov
2021-04-11 14:03       ` Eryu Guan
2021-04-21 19:13         ` Boris Burkov
2021-04-25  5:14           ` Eryu Guan
2021-04-07 20:27     ` Boris Burkov [this message]

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=YG4VkCWy3BK2zwnr@zen \
    --to=boris@bur.io \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@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 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 NNTP newsgroup(s).