From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz1sT-0005SI-R3 for qemu-devel@nongnu.org; Tue, 25 Oct 2016 09:34:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz1sP-0001MU-RR for qemu-devel@nongnu.org; Tue, 25 Oct 2016 09:34:53 -0400 Date: Tue, 25 Oct 2016 21:34:38 +0800 From: Fam Zheng Message-ID: <20161025133438.GA15298@lemon> References: <1475237406-26917-1-git-send-email-famz@redhat.com> <1475237406-26917-3-git-send-email-famz@redhat.com> <50c03fb7-5016-f6c4-f469-71706e9903da@redhat.com> <20161025053630.GB5427@lemon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v8 02/36] qapi: Add ImageLockMode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: qemu-devel@nongnu.org, berrange@redhat.com, John Snow , qemu-block@nongnu.org, Kevin Wolf , rjones@redhat.com, Jeff Cody , Markus Armbruster , stefanha@redhat.com, den@openvz.org, pbonzini@redhat.com, eblake@redhat.com 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 > >>> --- > >>> 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