On Mon, Aug 13, 2018 at 8:52 PM Eric Blake <[email protected]> wrote:
> On 08/03/2018 02:28 PM, Nir Soffer wrote: > > File systems not supporting FALLOC_FL_ZERO_RANGE yet fall back to manual > > zeroing. > > > > We can avoid this by combining two fallocate calls: > > > > fallocate(FALLOC_FL_PUNCH_HOLE) > > fallocate(0) > > > > Based on my tests this is much more efficient compared to manual > > zeroing. The idea came from this qemu patch: > > https://github.com/qemu/qemu/commit/1cdc3239f1bb > > > > > > > Note: the image is sparse, but nbdkit creates a fully allocated image. > > This may be a bug in nbdkit or qemu-img. > > Calling fallocate(0) forces allocation; so anything explicitly written > to 0 won't be sparse when this mode is used. Sure, this is a poor mans replacement for ZERO_RANGE. I assume that we want sparseness only when may_trim is set, which is the current behavior before this patch. With qemu-img the default is sparse, and using -o preallocation=falloc make the image preallocated. It seems that we don't have a way to select sparseness of the destination image in NBD, or maybe I'm missing something? > There's also a question of > whether your source file accurately reports holes to begin with (poor > tmpfs SEEK_HOLE performance is still a common problem). But I don't see > that as getting in the way of this patch going in. > Nir
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
