On Thu, Mar 28, 2024 at 04:39:08PM -0400, Stefan Hajnoczi wrote:
> The dm-linear linear target passes through SEEK_HOLE/SEEK_DATA. Extend
> the test case to check that the same holes/data are reported as for the
> underlying file.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@xxxxxxxxxx>
> ---
> tools/testing/selftests/block_seek_hole/test.py | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/block_seek_hole/test.py b/tools/testing/selftests/block_seek_hole/test.py
> index 4f7c2d01ab3d3..6360b72aee338 100755
> --- a/tools/testing/selftests/block_seek_hole/test.py
> +++ b/tools/testing/selftests/block_seek_hole/test.py
> @@ -45,6 +45,20 @@ def loop_device(file_path):
> finally:
> run(['losetup', '-d', loop_path])
>
> +@contextmanager
> +def dm_linear(file_path):
> + file_size = os.path.getsize(file_path)
> +
> + with loop_device(file_path) as loop_path:
> + dm_name = f'test-{os.getpid()}'
> + run(['dmsetup', 'create', dm_name, '--table',
> + f'0 {file_size // 512} linear {loop_path} 0'])
Would it be worth tryiing to create the dm with two copies of
loop_path concatenated one after the other? You'd have to do more
work on expected output (coalescing adjacent data or holes between the
tail of the first copy and the head of the second), but without that
in place, I worry that you are missing logic bugs for when there is
more than one table in the overall dm (as evidenced by my review in
4/9).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
