From: Eryu Guan <eguan@linux.alibaba.com>
To: Chengguang Xu <cgxu519@mykernel.net>
Cc: Su Yue <l@damenly.su>, guaneryu <guaneryu@gmail.com>,
fstests <fstests@vger.kernel.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-ext4 <linux-ext4@vger.kernel.org>,
linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] generic/473: fix expectation properly in out file
Date: Wed, 24 Feb 2021 21:31:46 +0800 [thread overview]
Message-ID: <20210224133146.GE96449@e18g06458.et15sqa> (raw)
In-Reply-To: <177d3666a3c.e47042d016248.8805085013477614929@mykernel.net>
On Wed, Feb 24, 2021 at 05:37:20PM +0800, Chengguang Xu wrote:
> ---- 在 星期三, 2021-02-24 17:22:35 Su Yue <l@damenly.su> 撰写 ----
> >
> > On Wed 24 Feb 2021 at 16:51, Chengguang Xu <cgxu519@mykernel.net>
> > wrote:
> >
> > > ---- 在 星期三, 2021-02-24 15:52:17 Su Yue <l@damenly.su> 撰写
> > > ----
> > > >
> > > > Cc to the author and linux-xfs, since it's xfsprogs related.
> > > >
> > > > On Tue 23 Feb 2021 at 21:40, Chengguang Xu
> > > > <cgxu519@mykernel.net>
> > > > wrote:
> > > >
> > > > > It seems the expected result of testcase of "Hole + Data"
> > > > > in generic/473 is not correct, so just fix it properly.
> > > > >
> > > >
> > > > But it's not proper...
> > > >
> > > > > Signed-off-by: Chengguang Xu <cgxu519@mykernel.net>
> > > > > ---
> > > > > tests/generic/473.out | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/tests/generic/473.out b/tests/generic/473.out
> > > > > index 75816388..f1ee5805 100644
> > > > > --- a/tests/generic/473.out
> > > > > +++ b/tests/generic/473.out
> > > > > @@ -6,7 +6,7 @@ Data + Hole
> > > > > 1: [256..287]: hole
> > > > > Hole + Data
> > > > > 0: [0..127]: hole
> > > > > -1: [128..255]: data
> > > > > +1: [128..135]: data
> > > > >
> > > > The line is produced by `$XFS_IO_PROG -c "fiemap -v 0 65k"
> > > > $file |
> > > > _filter_fiemap`.
> > > > 0-64k is a hole and 64k-128k is a data extent.
> > > > fiemap ioctl always returns *complete* ranges of extents.
> > >
> > > Manual testing result in latest kernel like below.
> > >
> > > [root@centos test]# uname -a
> > > Linux centos 5.11.0+ #5 SMP Tue Feb 23 21:02:27 CST 2021 x86_64
> > > x86_64 x86_64 GNU/Linux
> > >
> > > [root@centos test]# xfs_io -V
> > > xfs_io version 5.0.0
> > >
> > > [root@centos test]# stat a
> > > File: a
> > > Size: 4194304 Blocks: 0 IO Block: 4096
> > > regular file
> > > Device: fc01h/64513d Inode: 140 Links: 1
> > > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/
> > > root)
> > > Access: 2021-02-24 16:33:20.235654140 +0800
> > > Modify: 2021-02-24 16:33:25.070641521 +0800
> > > Change: 2021-02-24 16:33:25.070641521 +0800
> > > Birth: -
> > >
> > > [root@centos test]# xfs_io -c "pwrite 64k 64k" a
> > > wrote 65536/65536 bytes at offset 65536
> > > 64 KiB, 16 ops; 0.0000 sec (992.063 MiB/sec and 253968.2540
> > > ops/sec)
> > >
> > > [root@VM-8-4-centos test]# xfs_io -c "fiemap -v 0 65k" a
> > > a:
> > > EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
> > > 0: [0..127]: hole 128
> > > 1: [128..135]: 360..367 8 0x1
> > >
> >
> > Sorry, my carelessness. I only checked btrfs implementation but
> > xfs
> > and ext4 do return the change you made.
> >
>
> Yeah, it seems there is no bad side effect to show only specified range of extents
> and keep all the same behavior is also good for testing. I can post a fix patch for
> this but before that let us to wait some feedback from maintainers and experts.
generic/473 is marked as broken by commit 715eac1a9e66 ("generic/47[23]:
remove from auto/quick groups").
Thanks,
Eryu
next prev parent reply other threads:[~2021-02-24 15:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210223134042.2212341-1-cgxu519@mykernel.net>
[not found] ` <4ki1rjgu.fsf@damenly.su>
[not found] ` <177d33c0982.10b8858b515683.1169986601273192029@mykernel.net>
2021-02-24 9:16 ` [PATCH] generic/473: fix expectation properly in out file Chengguang Xu
[not found] ` <wnuxq0px.fsf@damenly.su>
2021-02-24 9:37 ` Chengguang Xu
2021-02-24 13:31 ` Eryu Guan [this message]
2021-02-24 13:48 ` Chengguang Xu
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=20210224133146.GE96449@e18g06458.et15sqa \
--to=eguan@linux.alibaba.com \
--cc=cgxu519@mykernel.net \
--cc=fstests@vger.kernel.org \
--cc=guaneryu@gmail.com \
--cc=l@damenly.su \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@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