| Message ID | 20201009215533.1194742-1-eblake@redhat.com |
|---|---|
| Headers | show |
| Series | Exposing backing-chain allocation over NBD | expand |
10.10.2020 00:55, Eric Blake wrote: > Each dirty bitmap already knows its name; by reducing the scope of the > places where we construct "qemu:dirty-bitmap:NAME" strings, tracking > the name is more localized, and there are fewer per-export fields to > worry about. This in turn will make it easier for an upcoming patch > to export more than one bitmap at once. > > Signed-off-by: Eric Blake<eblake@redhat.com> Thanks for updating this! Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
On 10/14/20 9:42 AM, Vladimir Sementsov-Ogievskiy wrote: > 10.10.2020 00:55, Eric Blake wrote: >> With this, 'qemu-nbd -B b0 -B b1 -f qcow2 img.qcow2' can let you sniff >> out multiple bitmaps from one server. qemu-img as client can still >> only read one bitmap per client connection, but other NBD clients >> (hello libnbd) can now read multiple bitmaps in a single pass. >> >> Signed-off-by: Eric Blake <eblake@redhat.com> > > > You didn't update nbd_export_create failure patch, I suggest: Good catch. I'm happy to fold in both of your suggestions.
On 10/16/20 10:23 AM, Eric Blake wrote: > A rather trivial decoding; we may enhance it further if qemu extends > things to give an integer depth alongside its tri-state encoding. > --- > > I'll wait to push this to libnbd until the counterpart qemu patches > land upstream, although it looks like I've got positive review. Whoops, I accidentally pushed this before qemu stuff landed upstream, and in the meantime, we changed our minds on what to expose over qemu:allocation-depth to be a bare integer rather than a tri-state. I'll push this followup (but this time, wait for the actual qemu patch to land). In fact, I should probably add test-suite coverage...
On Tue, Oct 27, 2020 at 10:33:48AM -0500, Eric Blake wrote: > On 10/16/20 10:23 AM, Eric Blake wrote: > > A rather trivial decoding; we may enhance it further if qemu extends > > things to give an integer depth alongside its tri-state encoding. > > --- > > > > I'll wait to push this to libnbd until the counterpart qemu patches > > land upstream, although it looks like I've got positive review. > > Whoops, I accidentally pushed this before qemu stuff landed upstream, > and in the meantime, we changed our minds on what to expose over > qemu:allocation-depth to be a bare integer rather than a tri-state. > I'll push this followup (but this time, wait for the actual qemu patch > to land). In fact, I should probably add test-suite coverage... ACK. I have a patch which touches this file but it's a simple merge to combine the two changes. Rich. > >From eba8734654e6fd340e18b3e07c3213ed1a0ab9e8 Mon Sep 17 00:00:00 2001 > From: Eric Blake <eblake@redhat.com> > Date: Tue, 27 Oct 2020 10:27:25 -0500 > Subject: [libnbd PATCH] info: Adjust to actual 'qemu-nbd -A' semantics > > Review on the qemu list has led to an altered definition of what > 'qemu:allocation-depth' should report: rather than a tri-state value, > it is an actual depth. It's time to match what actually got committed > into qemu, which in turn means a slight refactoring to use a malloc'd > string for a description. > > Fixes: 71455c021 > --- > info/nbdinfo.c | 27 +++++++++++++++------------ > 1 file changed, 15 insertions(+), 12 deletions(-) > > diff --git a/info/nbdinfo.c b/info/nbdinfo.c > index 2b22f51..b152f28 100644 > --- a/info/nbdinfo.c > +++ b/info/nbdinfo.c > @@ -767,28 +767,30 @@ get_content (struct nbd_handle *nbd, int64_t size) > } > > /* Callback handling --map. */ > -static const char * > +static char * > extent_description (const char *metacontext, uint32_t type) > { > + char *ret; > + > if (strcmp (metacontext, "base:allocation") == 0) { > switch (type) { > - case 0: return "allocated"; > - case 1: return "hole"; > - case 2: return "zero"; > - case 3: return "hole,zero"; > + case 0: return strdup ("allocated"); > + case 1: return strdup ("hole"); > + case 2: return strdup ("zero"); > + case 3: return strdup ("hole,zero"); > } > } > else if (strncmp (metacontext, "qemu:dirty-bitmap:", 18) == 0) { > switch (type) { > - case 0: return "clean"; > - case 1: return "dirty"; > + case 0: return strdup ("clean"); > + case 1: return strdup ("dirty"); > } > } > else if (strcmp (metacontext, "qemu:allocation-depth") == 0) { > - switch (type & 3) { > - case 0: return "unallocated"; > - case 1: return "local"; > - case 2: return "backing"; > + switch (type) { > + case 0: return strdup ("unallocated"); > + case 1: return strdup ("local"); > + case 2: asprintf (&ret, "backing depth %d", type); return ret; > } > } > > @@ -810,7 +812,7 @@ extent_callback (void *user_data, const char > *metacontext, > > /* Print the entries received. */ > for (i = 0; i < nr_entries; i += 2) { > - const char *descr = extent_description (map, entries[i+1]); > + char *descr = extent_description (map, entries[i+1]); > > if (!json_output) { > fprintf (fp, "%10" PRIu64 " " > @@ -837,6 +839,7 @@ extent_callback (void *user_data, const char > *metacontext, > comma = true; > } > > + free (descr); > offset += entries[i]; > } > > -- > 2.29.0 > > > > -- > 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