qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Eric Blake <eblake@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: kwolf@redhat.com, den@openvz.org, mreitz@redhat.com,
	nshirokovskiy@virtuozzo.com, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH] qapi: add dirty-bitmaps to query-named-block-nodes result
Date: Fri, 31 May 2019 14:22:11 -0400	[thread overview]
Message-ID: <2a9f6327-1cb6-78eb-ad10-93a33c6e754c@redhat.com> (raw)
In-Reply-To: <f9af022a-7acf-bb1c-3d2c-b095bff2e251@redhat.com>



On 5/31/19 10:55 AM, Eric Blake wrote:
> On 5/30/19 11:26 AM, John Snow wrote:
>>
>>
>> On 5/30/19 10:39 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> Let's add a possibility to query dirty-bitmaps not only on root nodes.
>>> It is useful when dealing both with snapshots and incremental backups.
>>>
> 
>>> +++ b/block/qapi.c
>>> @@ -78,6 +78,11 @@ BlockDeviceInfo *bdrv_block_device_info(BlockBackend *blk,
>>>          info->backing_file = g_strdup(bs->backing_file);
>>>      }
>>>  
>>> +    if (!QLIST_EMPTY(&bs->dirty_bitmaps)) {
>>> +        info->has_dirty_bitmaps = true;
>>> +        info->dirty_bitmaps = bdrv_query_dirty_bitmaps(bs);
>>> +    }
>>> +
>>>      info->detect_zeroes = bs->detect_zeroes;
>>>  
>>>      if (blk && blk_get_public(blk)->throttle_group_member.throttle_state) {
>>>
>>
>> So query-block uses bdrv_query_info, which calls bdrv_block_device_info,
>> so we'll duplicate the bitmap output when doing the old-fashioned block
>> query, but that's probably harmless overall.
> 
> We already know that none of our existing query- interfaces are sane
> (either too little information, or too much).  Duplication starts to
> push an interface towards too much (it takes processor time to bundle up
> the extra JSON, especially if the other end is not going to care if it
> was present). I know Kevin still has somewhere on his to-do list the
> implementation of a saner query- command for the information we really
> want (about each block, without redundant information, and where we
> don't repeat information in a nested manner, but where we also don't
> omit information that would otherwise require multiple existing query-
> to reconstruct).
> 
>>
>> We can continue to support the output in both places, or we could opt to
>> deprecate the older interface; I think this is one of the last chances
>> we'd get to do so before libvirt and wider adoption.
>>
>> I think that's probably Eric's choice.
> 
> If you want to try to deprecate the old location, introspection at least
> works to allow libvirt to know which place to look for it on a given
> qemu. If you don't think deprecation is necessary, the duplication is
> probably tolerable for now (as ideally we'd be deprecating ALL of our
> not-quite-perfect query- block interfaces in favor of whatever sane
> interface Kevin comes up with).
> 

It sounds like it's probably the right move to deprecate the entire
legacy interface, but still... If you have 20 or 30 bitmaps on a root
node, you will see 40 or 60 entries.

What's the smart way to deprecate it? We're not adding new flags or
showing new arguments or anything. There might not be bitmaps, so you
can't rely on that field being present or absent.

Recommendations?


  reply	other threads:[~2019-05-31 18:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30 14:39 [Qemu-devel] [PATCH] qapi: add dirty-bitmaps to query-named-block-nodes result Vladimir Sementsov-Ogievskiy
2019-05-30 15:01 ` Eric Blake
2019-05-30 16:26 ` John Snow
2019-05-31 14:55   ` Eric Blake
2019-05-31 18:22     ` John Snow [this message]
2019-06-05 12:46       ` Markus Armbruster
2019-07-16  0:13         ` John Snow
2019-07-16  6:32           ` Markus Armbruster
2019-07-16 15:26             ` John Snow
2019-07-17 15:57               ` John Snow

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=2a9f6327-1cb6-78eb-ad10-93a33c6e754c@redhat.com \
    --to=jsnow@redhat.com \
    --cc=armbru@redhat.com \
    --cc=den@openvz.org \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=nshirokovskiy@virtuozzo.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --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).