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