qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 11/18] block/backup: upgrade copy_bitmap to B


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH v2 11/18] block/backup: upgrade copy_bitmap to BdrvDirtyBitmap
Date: Mon, 8 Jul 2019 20:42:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 08.07.19 20:32, John Snow wrote:
> 
> 
> On 7/8/19 8:02 AM, Max Reitz wrote:
>> On 05.07.19 18:52, John Snow wrote:
>>>
>>>
>>> On 7/4/19 1:29 PM, Max Reitz wrote:
>>
>> [...]
>>
>>>> Which brings me to a question: Why is the copy bitmap assigned to the
>>>> target in the first place?  Wouldn’t it make more sense on the source?
>>>>
>>>
>>> *cough*;
>>>
>>> the idea was that the target is *most likely* to be the temporary node
>>> created for the purpose of this backup, even though backup does not
>>> explicitly create the node.
>>>
>>> So ... by creating it on the target, we avoid cluttering up the results
>>> in block query; and otherwise it doesn't actually matter what node we
>>> created it on, really.
>>>
>>> I can move it over to the source, but the testing code has to get a
>>> little smarter in order to find the "right" anonymous bitmap, which is
>>> not impossible; but I thought this would actually be a convenience for
>>> people.
>>
>> You didn’t really say whether you think it makes more sense on the
>> source or on the target.
>>
> 
> Yeah, a bitmap that isn't recording writes seems to make about equal
> sense on either to me; I chose the destination because it was more
> likely to be temporary (in the drive-backup case) and I considered this
> a temporary bitmap for use by the job.
> 
> Organizationally I felt that made sense. I realize it's also not
> strictly true for the blockdev-backup case, but it also doesn't matter
> terribly.
> 
> Semantically, it's a toss-up. Another coder could conceivably one day
> decided to re-enable this bitmap and then it would make more sense on
> the source. (That coder would be wrong to do that.)

Hm.  If we had a filter node like we do for mirror, it should be there,
clearly.

...is what I wanted to say.  But then I looked it up and found out that
mirror actually still puts its bitmap on the source node.

Sure, one of the differences between backup and mirror is that backup’s
bitmap does not record writes and thus it functionally doesn’t matter
where it’s placed.  But why make mirror and backup behave more
differently than necessary?  They should be a single block job anyway.

>> So for me, it comes down to where it makes more sense.  And I think it
>> makes more sense on the source, because it flags source clusters to copy.
>>
>> Max
>>
> 
> If you insist.

I guess I kind of do, yes.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]