On 4/25/19 5:37 AM, Richard W.M. Jones wrote: > On Wed, Apr 24, 2019 at 02:39:03PM -0500, Eric Blake wrote: >> On 3/28/19 11:18 AM, Richard W.M. Jones wrote: >>> This uses lseek SEEK_DATA/SEEK_HOLE to search for allocated data and >>> holes in the underlying file.
>> Should we also return 0 if the lseek() returned the offset of EOF?
>> reason against: if we expect NBD_CMD_TRIM/NBD_CMD_WRITE_ZEROES or even a
>> third-party to be punching holes in the meantime, then opting out of
>> future lseek() won't see those later additions of holes.
>
> This last point seems crucial - the file could become sparse, even if
> it starts off as non-sparse.
>
> The test is designed really to eliminate the case where SEEK_HOLE
> isn't supported and returns an error.
Okay, then let's leave this one as-is.
>
> However you rightly point out that there's another case we don't
> cover: what if we're using tmpfs where SEEK_HOLE is supported but has
> poor performance? I would say the best solution is to fix tmpfs! But
> if that's not possible, perhaps we can do {f,}statfs(2) on the file
> and blacklist certain combinations of f_type and kernel version?
Nah, it's easier to just tell the users to apply the noextents filter in
that case.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
