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

[Fam Zheng]

On Tue, 10/25 15:20, Max Reitz wrote:
> 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?

The guest can always corrupt data themselves so I think my wording is inaccurate
here. Actually the more reasonable case of this is for example when server side
locking is applied automatically and transparently:

https://lists.gnu.org/archive/html/qemu-devel/2016-04/msg03576.html

(I don't know how the mentioned feature above ended up at RBD side, but that
makes an interesting consideration point).

Fam