* Re: [PATCH] generic/473: fix expectation properly in out file [not found] <20210223134042.2212341-1-cgxu519@mykernel.net> @ 2021-02-24 7:52 ` Su Yue 2021-02-24 8:10 ` Su Yue [not found] ` <177d33c0982.10b8858b515683.1169986601273192029@mykernel.net> 0 siblings, 2 replies; 7+ messages in thread From: Su Yue @ 2021-02-24 7:52 UTC (permalink / raw) To: Chengguang Xu; +Cc: guaneryu, fstests, nborisov, linux-xfs 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. 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] 7+ messages in thread
* Re: [PATCH] generic/473: fix expectation properly in out file 2021-02-24 7:52 ` [PATCH] generic/473: fix expectation properly in out file Su Yue @ 2021-02-24 8:10 ` Su Yue 2021-02-24 8:55 ` Chengguang Xu [not found] ` <177d33c0982.10b8858b515683.1169986601273192029@mykernel.net> 1 sibling, 1 reply; 7+ messages in thread From: Su Yue @ 2021-02-24 8:10 UTC (permalink / raw) To: Chengguang Xu; +Cc: guaneryu, fstests, nborisov, linux-xfs On Wed 24 Feb 2021 at 15:52, Su Yue <l@damenly.su> wrote: > 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. > And what you want to change is only the filted output. Without _filter_fiemap: /mnt/test/fiemap.473: | EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS | 0: [0..127]: hole 128 | 1: [128..255]: 26792..26919 128 0x0 [128..255] corresponds to the BLOCK-RANGE of the extent 26792..26919. > 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] 7+ messages in thread
* Re: [PATCH] generic/473: fix expectation properly in out file 2021-02-24 8:10 ` Su Yue @ 2021-02-24 8:55 ` Chengguang Xu 0 siblings, 0 replies; 7+ messages in thread From: Chengguang Xu @ 2021-02-24 8:55 UTC (permalink / raw) To: Su Yue; +Cc: guaneryu, fstests, nborisov, linux-xfs ---- 在 星期三, 2021-02-24 16:10:39 Su Yue <l@damenly.su> 撰写 ---- > > On Wed 24 Feb 2021 at 15:52, Su Yue <l@damenly.su> wrote: > > > 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. > > > And what you want to change is only the filted output. > Without _filter_fiemap: Without _filter_fiemap: [root@centos xfstests-dev]# git diff diff --git a/tests/generic/473 b/tests/generic/473 index 5c19703e..35f28677 100755 --- a/tests/generic/473 +++ b/tests/generic/473 @@ -60,7 +60,8 @@ echo "Data + Hole" $XFS_IO_PROG -c "fiemap -v 64k 80k" $file | _filter_fiemap echo "Hole + Data" -$XFS_IO_PROG -c "fiemap -v 0 65k" $file | _filter_fiemap +#$XFS_IO_PROG -c "fiemap -v 0 65k" $file | _filter_fiemap +$XFS_IO_PROG -c "fiemap -v 0 65k" $file echo "Hole + Data + Hole" $XFS_IO_PROG -c "fiemap -v 0k 130k" $file | _filter_fiemap [root@centos xfstests-dev]# ./check generic/473 FSTYP -- ext4 PLATFORM -- Linux/x86_64 centos 5.11.0+ #5 SMP Tue Feb 23 21:02:27 CST 2021 MKFS_OPTIONS -- /dev/mapper/workvg-test2 MOUNT_OPTIONS -- -o acl,user_xattr /dev/mapper/workvg-test2 /mnt/scratch generic/473 1s ... - output mismatch (see /git/xfstests-dev/results//generic/473.out.bad) --- tests/generic/473.out 2021-02-24 16:51:23.254845067 +0800 +++ /git/xfstests-dev/results//generic/473.out.bad 2021-02-24 16:52:04.440737816 +0800 @@ -5,8 +5,10 @@ 0: [128..255]: data 1: [256..287]: hole Hole + Data -0: [0..127]: hole -1: [128..255]: data +/mnt/test/fiemap.473: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS ... (Run 'diff -u /git/xfstests-dev/tests/generic/473.out /git/xfstests-dev/results//generic/473.out.bad' to see the entire diff) Ran: generic/473 Failures: generic/473 Failed 1 of 1 tests [root@centos xfstests-dev]# diff -u /git/xfstests-dev/tests/generic/473.out /git/xfstests-dev/results//generic/473.out.bad --- /git/xfstests-dev/tests/generic/473.out 2021-02-24 16:51:23.254845067 +0800 +++ /git/xfstests-dev/results//generic/473.out.bad 2021-02-24 16:52:04.440737816 +0800 @@ -5,8 +5,10 @@ 0: [128..255]: data 1: [256..287]: hole Hole + Data -0: [0..127]: hole -1: [128..255]: data +/mnt/test/fiemap.473: + EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS + 0: [0..127]: hole 128 + 1: [128..135]: 274560..274567 8 0x1 Hole + Data + Hole 0: [0..127]: hole 1: [128..255]: data > > /mnt/test/fiemap.473: > | > EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS > | > 0: [0..127]: hole 128 > | > 1: [128..255]: 26792..26919 128 0x0 > > [128..255] corresponds to the BLOCK-RANGE of the extent > 26792..26919. > > > 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 related [flat|nested] 7+ messages in thread
[parent not found: <177d33c0982.10b8858b515683.1169986601273192029@mykernel.net>]
* 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; 7+ 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] 7+ 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; 7+ 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] 7+ 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; 7+ 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] 7+ 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; 7+ 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] 7+ messages in thread
end of thread, other threads:[~2021-02-24 15:06 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20210223134042.2212341-1-cgxu519@mykernel.net>
2021-02-24 7:52 ` [PATCH] generic/473: fix expectation properly in out file Su Yue
2021-02-24 8:10 ` Su Yue
2021-02-24 8:55 ` Chengguang Xu
[not found] ` <177d33c0982.10b8858b515683.1169986601273192029@mykernel.net>
2021-02-24 9:16 ` 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