[Libguestfs] [PATCH v2 2/4] file: Support zero without ZERO_RANGE

[Nir Soffer]

On Mon, Aug 13, 2018 at 8:52 PM Eric Blake <eblake at redhat.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180814/c16f27f8/attachment.htm>