[Top][All Lists]

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

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

From: Max Reitz
Subject: Re: [Qemu-block] [PATCH v8 02/36] qapi: Add ImageLockMode
Date: Tue, 25 Oct 2016 15:20:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

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


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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