qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-devel@nongnu.org
Cc: kwolf@redhat.com, pkrempa@redhat.com, qemu-block@nongnu.org,
	rjones@redhat.com, Max Reitz <mreitz@redhat.com>,
	stefanha@redhat.com
Subject: Re: [PATCH v2 4/5] nbd: Add new qemu:allocation-depth metacontext
Date: Wed, 7 Oct 2020 16:54:42 -0500	[thread overview]
Message-ID: <f839054c-70e6-cfe5-0c44-e9a519389d65@redhat.com> (raw)
In-Reply-To: <1425ef36-614e-f6eb-ff41-90693d017fbb@virtuozzo.com>


[-- Attachment #1.1: Type: text/plain, Size: 5528 bytes --]

On 10/7/20 8:40 AM, Vladimir Sementsov-Ogievskiy wrote:
> 30.09.2020 15:11, Eric Blake wrote:
>> 'qemu-img map' provides a way to determine which extents of an image
>> come from the top layer vs. inherited from a backing chain.  This is
>> useful information worth exposing over NBD.  There is a proposal to
>> add a QMP command block-dirty-bitmap-populate which can create a dirty
>> bitmap that reflects allocation information, at which point
>> qemu:dirty-bitmap:NAME can expose that information via the creation of
>> a temporary bitmap, but we can shorten the effort by adding a new
>> qemu:allocation-depth context that does the same thing without an
>> intermediate bitmap (this patch does not eliminate the need for that
>> proposal, as it will have other uses as well).
>>
>> For this patch, I just encoded a tri-state value (unallocated, from
>> this layer, from any of the backing layers); an obvious extension
>> would be to provide the actual depth in bits 31-4 while keeping bits
>> 1-0 as a tri-state (leaving bits 3-2 unused, for ease of reading depth
>> from a hex number).  But this extension would require
>> bdrv_is_allocated_above to return a depth number.
>>
>> Note that this patch does not actually enable any way to request a
>> server to enable this context; that will come in the next patch.
>>

>> +In the allocation depth context, bits 0 and 1 form a tri-state value:
>> +
>> +    bits 0-1 clear: NBD_STATE_DEPTH_UNALLOC, means the extent is
>> unallocated
>> +    bit 0 set: NBD_STATE_DEPTH_LOCAL, the extent is allocated in this
>> image
> 
> Maybe, s/this/the top level/, as, what is "this" for NBD client?

Sure.


>> @@ -864,12 +867,21 @@ static bool nbd_meta_qemu_query(NBDClient
>> *client, NBDExportMetaContexts *meta,
>>
>>       if (!*query) {

We get here for "qemu:".

>>           if (client->opt == NBD_OPT_LIST_META_CONTEXT) {
>> +            meta->allocation_depth = meta->exp->alloc_context;
>>               meta->bitmap = !!meta->exp->export_bitmap;
>>           }
>>           trace_nbd_negotiate_meta_query_parse("empty");
>>           return true;
>>       }
>>
>> +    if (nbd_strshift(&query, "allocation-depth")) {

We get here for "qemu:allocation-depth", and as you pointed out,
"qemu:allocation-depth-extended".

>> +        trace_nbd_negotiate_meta_query_parse("allocation-depth");
>> +        if (nbd_meta_empty_or_pattern(client, "", query)) {
> 
> How much it differs from "if (!*query) {", I don't see...

The nbd_meta_empty_or_pattern returns false for
"qemu:allocation-depth-extended"; it only returns true for
"qemu:allocation-depth".  But, as you pointed out,

> 
>> +            meta->allocation_depth = meta->exp->alloc_context;
>> +        }
>> +        return true;
>> +    }
> 
> why not just
> 
>  if (!strcmp(query, "allocation-depth")) {
>     meta->allocation_depth = meta->exp->alloc_context;
>     return true;
>  }
> 
> ?

that does seem shorter.

> 
> With your code you also parse something like
> "allocation-depth-extended".. Is it on purpose?

The string is parsed, but does not affect meta->XXX, which means nothing
gets advertised to the client.  The trace messages might differ, but
behavior is correct.

> 
>> +
>>       if (nbd_strshift(&query, "dirty-bitmap:")) {
>>           trace_nbd_negotiate_meta_query_parse("dirty-bitmap:");
>>           if (!meta->exp->export_bitmap) {
> 
> 
> Also, "trace_nbd_negotiate_meta_query_skip("not dirty-bitmap"); " at
> function end should
> now be something like trace_nbd_negotiate_meta_query_skip("unknown
> context in qemu: namespace");

Good idea.


>> +/* Get allocation depth from the exported device and send it to the
>> client */
>> +static int nbd_co_send_block_alloc(NBDClient *client, uint64_t handle,
>> +                                   BlockDriverState *bs, uint64_t
>> offset,
>> +                                   uint32_t length, bool dont_fragment,
>> +                                   bool last, uint32_t context_id,
>> +                                   Error **errp)
>> +{
>> +    int ret;
>> +    unsigned int nb_extents = dont_fragment ? 1 :
>> NBD_MAX_BLOCK_STATUS_EXTENTS;
>> +    g_autoptr(NBDExtentArray) ea = nbd_extent_array_new(nb_extents);
>> +
>> +    ret = blockalloc_to_extents(bs, offset, length, ea);
>> +    if (ret < 0) {
>> +        return nbd_co_send_structured_error(
>> +                client, handle, -ret, "can't get block status", errp);
>> +    }
>> +
>> +    return nbd_co_send_extents(client, handle, ea, last, context_id,
>> errp);
>> +}
> 
> 
> The function is a copy of nbd_co_send_block_status()..
> 
> Probably, we can reuse nbd_co_send_block_status(), and just call
> blockstatus_to_extents()
> or blockalloc_to_extents() depending on context_id parameter.

Nice idea to reduce the duplication.

> 
> Still, I'm OK with it as is.
> 

So is that Reviewed-by:, or do I need to post v3 with my tweaks in
response to your comments?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-10-07 21:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30 12:11 [PATCH v2 0/5] Exposing backing-chain allocation over NBD Eric Blake
2020-09-30 12:11 ` [PATCH v2 1/5] qemu-nbd: Honor SIGINT and SIGHUP Eric Blake
2020-10-07 10:32   ` Vladimir Sementsov-Ogievskiy
2020-10-07 21:13     ` Eric Blake
2020-10-08  8:27       ` Vladimir Sementsov-Ogievskiy
2020-09-30 12:11 ` [PATCH v2 2/5] nbd/server: Reject embedded NUL in NBD strings Eric Blake
2020-10-07 10:39   ` Vladimir Sementsov-Ogievskiy
2020-09-30 12:11 ` [PATCH v2 3/5] nbd: Simplify meta-context parsing Eric Blake
2020-10-07 11:51   ` Vladimir Sementsov-Ogievskiy
2020-10-07 21:28     ` Eric Blake
2020-09-30 12:11 ` [PATCH v2 4/5] nbd: Add new qemu:allocation-depth metacontext Eric Blake
2020-10-07 13:40   ` Vladimir Sementsov-Ogievskiy
2020-10-07 21:54     ` Eric Blake [this message]
2020-10-08 13:04       ` Vladimir Sementsov-Ogievskiy
2020-09-30 12:11 ` [PATCH v2 5/5] nbd: Add 'qemu-nbd -A' to expose allocation depth Eric Blake
2020-10-07 14:03   ` Vladimir Sementsov-Ogievskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f839054c-70e6-cfe5-0c44-e9a519389d65@redhat.com \
    --to=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).