Cc to the author and linux-xfs, since it's xfsprogs related.
On Tue 23 Feb 2021 at 21:40, Chengguang Xu <cgxu519@xxxxxxxxxxxx>
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@xxxxxxxxxxxx>
---
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
