Re: [Qemu-devel] [Qemu-block] [PATCH] blockdev-backup: enable non-root nodes for backup

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3788 bytes --]

On 2017-12-08 18:09, John Snow wrote:
> 
> 
> On 12/08/2017 09:30 AM, Max Reitz wrote:
>> On 2017-12-05 01:48, John Snow wrote:
>>>
>>>
>>> On 12/04/2017 05:21 PM, Max Reitz wrote:
>>>> On 2017-12-04 23:15, John Snow wrote:
>>>>>
>>>>>
>>>>> On 12/01/2017 02:41 PM, Max Reitz wrote:
>>>>>> ((By the way, I don't suppose that's how it should work...  But I don't
>>>>>> suppose that we want propagation of dirtying towards the BDS roots, do
>>>>>> we? :-/))
>>>>>
>>>>> I have never really satisfactorily explained to myself what bitmaps on
>>>>> intermediate notes truly represent or mean.
>>>>>
>>>>> The simple case is "This layer itself serviced a write request."
>>>>>
>>>>> If that information is not necessarily meaningful, I'm not sure that's a
>>>>> problem except in configuration.
>>>>>
>>>>>
>>>>> ...Now, if you wanted to talk about bitmaps that associate with a
>>>>> Backend instead of a Node...
>>>>
>>>> But it's not about bitmaps on intermediate nodes, quite the opposite.
>>>> It's about bitmaps on roots but write requests happening on intermediate
>>>> nodes.
>>>>
>>>
>>> Oh, I see what you're saying. It magically doesn't really change my
>>> opinion, by coincidence!
>>>
>>>> Say you have a node I and two filter nodes A and B using it (and they
>>>> are OK with shared writers).  There is a dirty bitmap on A.
>>>>
>>>> Now when a write request goes through B, I will obviously have changed,
>>>> and because A and B are filters, so will A.  But the dirty bitmap on A
>>>> will still be clean.
>>>>
>>>> My example was that when you run a mirror over A, you won't see dirtying
>>>> from B.  So you can't e.g. add a throttle driver between a mirror job
>>>> and the node you want to mirror, because the dirty bitmap on the
>>>> throttle driver will not be affected by accesses to the actual node.
>>>>
>>>> Max
>>>>
>>>
>>> Well, in this case I would say that a root BDS is not really any
>>> different from an intermediate one and can't really know what's going on
>>> in the world outside.
>>>
>>> At least, I think that's how we model it right now -- we pretend that we
>>> can record the activity of an entire drive graph by putting the bitmap
>>> on the root-most node we can get a hold of and assuming that all writes
>>> are going to go through us.
>>
>> Well, yeah, I know we do.  But I consider this counter-intuitive and if
>> something is counter-intuitive it's often a bug.
>>
>>> Clearly this is increasingly false the more we modularise the block graph.
>>>
>>>
>>> *uhm*
>>>
>>>
>>> I would say that a bitmap attached to a BlockBackend should behave in
>>> the way you say: writes to any children should change the bitmap here.
>>>
>>> bitmaps attached to nodes shouldn't worry about such things.
>>
>> Do we have bitmaps attached to BlockBackends?  I sure hope not.
>>
>> We should not have any interface that requires the use of BlockBackends
>> by now.  If we do, that's something that has to be fixed.
>>
>> Max
>>
> 
> I'm not sure what the right paradigm is anymore, then.
> 
> A node is just a node, but something has to represent the "drive" as far
> as the device model sees it. I thought that *was* the BlockBackend, but
> is it not?

Yes, and on the other side the BB represents the device model for the
block layer.  But the thing is that the user should be blissfully
unaware...  Or do you want to make bitmaps attachable to guest devices
(through the QOM path or ID) instead?

(The block layer would then internally translate that to a BB.  But
that's a bad internal interface because the bitmap is still attached to
a BDS, and it's a bad external interface because currently you can
attach bitmaps to nodes and only to nodes...)

Max


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