qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH 09/25] block/dirty-bitmap: add read


From: John Snow
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 09/25] block/dirty-bitmap: add readonly field to BdrvDirtyBitmap
Date: Fri, 2 Jun 2017 14:46:37 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0


On 06/02/2017 05:45 AM, Vladimir Sementsov-Ogievskiy wrote:
> 02.06.2017 12:01, Vladimir Sementsov-Ogievskiy wrote:
>> 02.06.2017 11:56, Vladimir Sementsov-Ogievskiy wrote:
>>> 02.06.2017 02:25, John Snow wrote:
>>>>
>>>> On 06/01/2017 03:30 AM, Sementsov-Ogievskiy Vladimir wrote:
>>>>> Hi John!
>>>>>
>>>>> Look at our discussion about this in v18 thread.
>>>>>> Shortly: readonly is not the same as disabled. disabled= bitmap just
>>>>> ignores all writes. readonly= writes are not allowed at all.
>>>>>
>>>>> And I think, I'll try to go through way 2: "dirty" field instead of
>>>>> "readonly" (look at v18 discussion), as it a bit more flexible.
>>>>>
>>>> Not sure which I prefer...
>>>>
>>>> Method 1 is attractive in that it is fairly simple, and enforces fairly
>>>> loudly the inability to write to devices with RO bitmaps. It's a
>>>> natural
>>>> extension of your current approach.
>>>
>>> For now I decided to realize this one, I think I'll publish it today.
>>> Also, I'm going to rename s/readonly/in_use - to avoid the confuse
>>> with disabled. So let this field just be mirror of IN_USE in the
>>> image and just say "persistent storage knows, that bitmap is in use
>>> and may be dirty".
> 
> Finally it would be readonly. in_use is bad for created (not loaded)
> bitmaps. I'll add more descriptive comments for disabled and readonly.
> 

Makes sense. It sounds like "readonly" is simply a stricter superset of
"disabled," where "disabled" doesn't care if the bitmap gets out of sync
with the data, but "readonly" attempts to preserve that semantic
relationship.

>>>
>>> Also, optimization with 'dirty' flag may be added later.
>>

Yes, I agree.

>> And, also, I don't want to influence this "first write", on which we
>> will set "IN_USE" in all bitmaps (for way (2). Reopening rw is less
>> performance-demanding place than write.
>>

"And, also," -- I think you've been reading my emails too much, you're
picking up my 'isms ;)

Thanks,
--John



reply via email to

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