Re: [Qemu-devel] [PATCH v8 02/36] qapi: Add ImageLockMode

[Max Reitz]

On 25.10.2016 07:36, Fam Zheng wrote:
> On Fri, 10/21 22:45, Max Reitz wrote:
>> On 30.09.2016 14:09, Fam Zheng wrote:
>>> Signed-off-by: Fam Zheng <address@hidden>
>>> ---
>>>  qapi/block-core.json | 18 ++++++++++++++++++
>>>  1 file changed, 18 insertions(+)
>>>
>>> diff --git a/qapi/block-core.json b/qapi/block-core.json
>>> index 92193ab..22e8d04 100644
>>> --- a/qapi/block-core.json
>>> +++ b/qapi/block-core.json
>>> @@ -2754,3 +2754,21 @@
>>>    'data' : { 'parent': 'str',
>>>               '*child': 'str',
>>>               '*node': 'str' } }
>>> +
>>> +##
>>> +# @ImageLockMode:
>>> +#
>>> +# @auto: defer to the block driver to use the least strict mode, based on
>>> +#        the nature of format and read-only flag, and the supported locking
>>> +#        operations of the protocol.
>>
>> I have some difficulty understanding this description. I'd intuitively
>> assume no locking to be the "least strict mode"; however, since it
>> should be always possible not to lock an image, this would mean that
>> auto=nolock. Which is hopefully isn't.
>>
>> If it's not easy to come up with a thorough explanation, perhaps it
>> would be best to give some examples which help to understand the concept
>> behind "auto" intuitively.
> 
> It could have beeen more specific, it's my bad being too terse here. Maybe
> something like this:
> 
>     @auto: defer to the block layer to use an appropriate lock mode, based on
>            the driver used and read-only option: for read-only images, shared
>            lock mode, or otherwise exclusive lock mode, will be attempted; if
>            the driver doesn't support this mode (or sharing is particularly
>            desired by its design), nolock will be used.
> 
> ?

Sounds good to me, if that's how it's supposed to be.

Do we actually want to use nolock "if sharing is particularly desired by
its design"? I mean, I think one of the drivers that would apply to is
NBD, but is the fact that multiple parties can freely access (and write
to!) an NBD disk at the same time really what we want or just a design
limitation?

Max

signature.asc
Description: OpenPGP digital signature