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

_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Reply via email to