From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55053) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz1eT-0002D4-2W for qemu-devel@nongnu.org; Tue, 25 Oct 2016 09:20:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz1eS-0005dp-2d for qemu-devel@nongnu.org; Tue, 25 Oct 2016 09:20:25 -0400 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> From: Max Reitz Message-ID: Date: Tue, 25 Oct 2016 15:20:16 +0200 MIME-Version: 1.0 In-Reply-To: <20161025053630.GB5427@lemon> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cjfqrnBOq0mp164ScV0M0suk78u9X0Mc9" Subject: Re: [Qemu-devel] [PATCH v8 02/36] qapi: Add ImageLockMode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng 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 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cjfqrnBOq0mp164ScV0M0suk78u9X0Mc9 From: Max Reitz To: Fam Zheng 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 Message-ID: Subject: Re: [PATCH v8 02/36] qapi: Add ImageLockMode 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> In-Reply-To: <20161025053630.GB5427@lemon> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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, bas= ed 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=3Dnolock. 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 conce= pt >> behind "auto" intuitively. >=20 > It could have beeen more specific, it's my bad being too terse here. Ma= ybe > something like this: >=20 > @auto: defer to the block layer to use an appropriate lock mode, ba= sed on > the driver used and read-only option: for read-only images, = shared > lock mode, or otherwise exclusive lock mode, will be attempt= ed; if > the driver doesn't support this mode (or sharing is particul= arly > desired by its design), nolock will be used. >=20 > ? 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 --cjfqrnBOq0mp164ScV0M0suk78u9X0Mc9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEvBAEBCAAZBQJYD1wQEhxtcmVpdHpAcmVkaGF0LmNvbQAKCRD0B9sAYdXPQAPM B/4/kOfek6AlfB91/8SUX+69B9T2fSlvPm5FbqqSxRq4dV2PjUtxEfPMgVNNNwn1 tYoxDgITNxIb7sl7LejgG3wShmUKUlnSYjcz+3zjv3EFmgauCAlNF5sSwMcSWBak 9BDRsrwCSHXz1tKdA03qm4V33bItcF9nV0gBGERTOi5j0GVe/CTGe11DDtPkrpaB otIuPlwphvXRLe5Obqgvd7fPvbdcc8LUnWXy9iwZoX9KEhUJ5f1G3ndoHINQLa0Y tQSWlDhtnw6glOaLHlN90dBgsoNqS/DeDowCE6waogCOTIt8I5AC0xibD26d1n9v d2cYMBL6vZQKpkLAEpghFc26 =gKz4 -----END PGP SIGNATURE----- --cjfqrnBOq0mp164ScV0M0suk78u9X0Mc9--