linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH] generic/473: fix expectation properly in out file
       [not found]   ` <177d33c0982.10b8858b515683.1169986601273192029@mykernel.net>
@ 2021-02-24  9:16     ` Chengguang Xu
       [not found]     ` <wnuxq0px.fsf@damenly.su>
  1 sibling, 0 replies; 4+ messages in thread
From: Chengguang Xu @ 2021-02-24  9:16 UTC (permalink / raw)
  To: Su Yue
  Cc: guaneryu, fstests, linux-fsdevel, linux-ext4, linux-xfs, linux-btrfs

 ---- 在 星期三, 2021-02-24 16:51:03 Chengguang Xu <cgxu519@mykernel.net> 撰写 ----
 >  ---- 在 星期三, 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.

Finally, I found btrfs returns *complete* rangne of extents but xfs/ext4 does not. :-/


[root@VM-89-226-centos /test]# xfs_io -c "fiemap 0 65k" a
a:
        0: [0..127]: hole
        1: [128..255]: 24576..24703
[root@VM-89-226-centos /test]# xfs_io -c "fiemap 0 128k" a
a:
        0: [0..127]: hole
        1: [128..255]: 24576..24703



 > 
 > 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
 >    
 > [root@centos test]# xfs_io -c "fiemap -v 0 128k" a
 > a:
 >  EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
 >    0: [0..127]:        hole               128
 >    1: [128..255]:      360..487           128   0x1
 > 
 > 
 >  > 
 >  > You may ask why the ending hole range is not aligned to 128 in 
 >  > 473.out. Because
 >  > fiemap ioctl returns nothing of querying holes. xfs_io does the 
 >  > extra
 >  > print work for holes.
 >  > 
 >  > xfsprogs-dev/io/fiemap.c:
 >  > for holes:
 >  >  153     if (lstart > llast) {
 >  >  154         print_hole(0, 0, 0, cur_extent, lflag, true, llast, 
 >  >  lstart);
 >  >  155         cur_extent++;
 >  >  156         num_printed++;
 >  >  157     }
 >  > 
 >  > for the ending hole:
 >  >   381     if (cur_extent && last_logical < range_end)
 >  >   382         print_hole(foff_w, boff_w, tot_w, cur_extent, lflag, 
 >  >   !vflag,
 >  >   383                BTOBBT(last_logical), BTOBBT(range_end));
 >  > 
 >  > >  Hole + Data + Hole
 >  > >  0: [0..127]: hole
 >  > >  1: [128..255]: data
 >  > 
 > 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] generic/473: fix expectation properly in out file
       [not found]     ` <wnuxq0px.fsf@damenly.su>
@ 2021-02-24  9:37       ` Chengguang Xu
  2021-02-24 13:31         ` Eryu Guan
  0 siblings, 1 reply; 4+ messages in thread
From: Chengguang Xu @ 2021-02-24  9:37 UTC (permalink / raw)
  To: Su Yue
  Cc: guaneryu, fstests, linux-btrfs, linux-fsdevel, linux-ext4, linux-xfs

 ---- 在 星期三, 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.

Thanks,
Chengguang


 > 
 > > [root@centos test]# xfs_io -c "fiemap -v 0 128k" a
 > > a:
 > >  EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
 > >    0: [0..127]:        hole               128
 > >    1: [128..255]:      360..487           128   0x1
 > >
 > >
 > >  >
 > >  > You may ask why the ending hole range is not aligned to 128 
 > >  > in
 > >  > 473.out. Because
 > >  > fiemap ioctl returns nothing of querying holes. xfs_io does 
 > >  > the
 > >  > extra
 > >  > print work for holes.
 > >  >
 > >  > xfsprogs-dev/io/fiemap.c:
 > >  > for holes:
 > >  >  153     if (lstart > llast) {
 > >  >  154         print_hole(0, 0, 0, cur_extent, lflag, true, 
 > >  >  llast,
 > >  >  lstart);
 > >  >  155         cur_extent++;
 > >  >  156         num_printed++;
 > >  >  157     }
 > >  >
 > >  > for the ending hole:
 > >  >   381     if (cur_extent && last_logical < range_end)
 > >  >   382         print_hole(foff_w, boff_w, tot_w, cur_extent, 
 > >  >   lflag,
 > >  >   !vflag,
 > >  >   383                BTOBBT(last_logical), 
 > >  >   BTOBBT(range_end));
 > >  >
 > >  > >  Hole + Data + Hole
 > >  > >  0: [0..127]: hole
 > >  > >  1: [128..255]: data
 > >  >
 > 
 > 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] generic/473: fix expectation properly in out file
  2021-02-24  9:37       ` Chengguang Xu
@ 2021-02-24 13:31         ` Eryu Guan
  2021-02-24 13:48           ` Chengguang Xu
  0 siblings, 1 reply; 4+ messages in thread
From: Eryu Guan @ 2021-02-24 13:31 UTC (permalink / raw)
  To: Chengguang Xu
  Cc: Su Yue, guaneryu, fstests, linux-btrfs, linux-fsdevel,
	linux-ext4, linux-xfs

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] generic/473: fix expectation properly in out file
  2021-02-24 13:31         ` Eryu Guan
@ 2021-02-24 13:48           ` Chengguang Xu
  0 siblings, 0 replies; 4+ messages in thread
From: Chengguang Xu @ 2021-02-24 13:48 UTC (permalink / raw)
  To: Eryu Guan
  Cc: Su Yue, guaneryu, fstests, linux-btrfs, linux-fsdevel,
	linux-ext4, linux-xfs

 ---- 在 星期三, 2021-02-24 21:31:46 Eryu Guan <eguan@linux.alibaba.com> 撰写 ----
 > 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").
 > 

I got it, thanks Eryu!



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-02-24 15:10 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [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
2021-02-24 13:48           ` Chengguang Xu

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