* 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
[parent not found: <wnuxq0px.fsf@damenly.su>]
* 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:06 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