Re: [Libguestfs] [nbdkit PATCH 04/10] plugins: Wire up in-memory plugin support for NBD_INFO_INIT_STATE
On 2/11/20 4:48 AM, Richard W.M. Jones wrote:
On Mon, Feb 10, 2020 at 03:43:57PM -0600, Eric Blake wrote:
> +/* Does current client start with a sparse image. */
> +static int
> +memory_init_sparse (void *handle)
> +{
> + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock);
> + return sparse_array_is_sparse (sa);
> +}
> +
> +/* Does current client start with all zeroes. */
> +static int
> +memory_init_zero (void *handle)
> +{
> + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock);
> + return sparse_array_is_zero (sa);
> +}
I was going to say these are always true, but then I remembered that
NBD_INIT_* records the state at the start of the *connection*, not the
start of the *server* instance, and if there's been a previous
connection then the RAM disk might indeed contain non-zero non-sparse
data.
Yes, and in fact the added testsuite case for test-memory-init.sh proves
this.
Do we need to define what NBD_INIT_ZERO means when disk size = 0 ?
I think it can be left ambiguous. The NBD protocol says .pread with
length 0 is unspecified. Logically, returning 1 means 'every byte that
you read is 0', and since you can't read any bytes, returning 1 is not a
problem (you can't read any bytes to prove the bit wrong). Requiring a
return of 0 for that corner case doesn't seem worth it. (The init bits
are really more of a 'yes-or-maybe', not a 'yes-or-no'. It is ALWAYS
fine to return 0, even if the condition actually holds).
By the way, the data plugin can also be updated since it also uses the
sparse array feature.
Yes, and that was done as part of this commit; from the commit message
that you trimmed:
plugins, it is fairly easy to advertise several cases: data and
memory
are usually sparse and detecting zero is easy (requires new functions
to the sparse_array common code), although since the sparse array is
reused between consecutive clients, a later client might get different
answers than the first client. The null and full plugins are
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org