On Thu, Aug 20, 2020 at 13:17:42 +0100, Daniel Berrange wrote:
On Thu, Aug 20, 2020 at 01:02:55PM +0200, Peter Krempa wrote:
> On Tue, Jul 07, 2020 at 21:46:26 +0200, Michal Privoznik wrote:
> > This function will be used to detect zero buffers (which are
> > going to be interpreted as hole in virStream later).
> >
> > I shamelessly took inspiration from coreutils.
>
> Coreutils is proudly GPLv3 ...
>
> > Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
> > ---
[...]
> Do we really need to do this optimization? We could arguably
simplify
> this to:
>
> if (*buf != '\0')
> return false;
>
> return memcmp(buf, buf + 1, len - 1);
Depends whether we care about this sparsification having goood
performance or not. As a point of reference, QEMU has invested
tonnes of effort in its impl, using highly tuned impls for
SSE, AVX, etc switched at runtime.
Well, comments to other patches in this series question whether we
actually want to do explicit sparsification at all.
Users always can explicitly sparsify their storage using the qemu tools
and the implementation this series adds (the sparsification on read) is
IMO actually stretching the semantics of the _SPARSE_STREAM flag too
much and creating different behaviour depending on whether a block
device is used (full sparsification) or a file is used (sparseness of
the file is preserved, explicitly allocated but zeroed blocks are
transported in full).