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 <f...@redhat.com>
> >>> ---
> >>> 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
