On Thu, Mar 28, 2024 at 05:19:26PM -0500, Eric Blake wrote: > On Thu, Mar 28, 2024 at 04:39:06PM -0400, Stefan Hajnoczi wrote: > > Signed-off-by: Stefan Hajnoczi <stefanha@xxxxxxxxxx> > > --- > > .../selftests/block_seek_hole/Makefile | 2 +- > > .../testing/selftests/block_seek_hole/config | 2 ++ > > .../selftests/block_seek_hole/dm_zero.sh | 31 +++++++++++++++++++ > > 3 files changed, 34 insertions(+), 1 deletion(-) > > create mode 100755 tools/testing/selftests/block_seek_hole/dm_zero.sh > > > > > +++ b/tools/testing/selftests/block_seek_hole/dm_zero.sh > > @@ -0,0 +1,31 @@ > > +#!/bin/sh > > +# SPDX-License-Identifier: GPL-2.0-only > > +# > > +# dm_zero.sh > > +# > > +# Test that dm-zero reports data because it does not have a custom > > +# SEEK_HOLE/SEEK_DATA implementation. > > Why not? Wouldn't it make more sense to have dm-zero report the > entire device as a hole (that is, an in-range SEEK_HOLE always returns > the same offset, while an in-range SEEK_DATA returns the device size)? Yes, dm-zero could report a hole. I just added this test to verify that targets that do not implement seek_hole_data() work and the dm-zero target was convenient for testing. Stefan > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. > Virtualization: qemu.org | libguestfs.org >
Attachment:
signature.asc
Description: PGP signature
