From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz1oe-0002af-6N for qemu-devel@nongnu.org; Tue, 25 Oct 2016 09:31:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz1od-0000Lb-8N for qemu-devel@nongnu.org; Tue, 25 Oct 2016 09:30:56 -0400 References: <1475237406-26917-1-git-send-email-famz@redhat.com> <20161024101111.GB4374@noname.redhat.com> <20161025082435.GA4695@noname.str.redhat.com> From: Max Reitz Message-ID: <527aa7ab-3e62-90d9-3551-22036e2ce7fe@redhat.com> Date: Tue, 25 Oct 2016 15:30:43 +0200 MIME-Version: 1.0 In-Reply-To: <20161025082435.GA4695@noname.str.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NJgFhONrR99PsdAINqkK4u8SqKk5vPr07" Subject: Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Fam Zheng , qemu-devel@nongnu.org, berrange@redhat.com, John Snow , qemu-block@nongnu.org, 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) --NJgFhONrR99PsdAINqkK4u8SqKk5vPr07 From: Max Reitz To: Kevin Wolf Cc: Fam Zheng , qemu-devel@nongnu.org, berrange@redhat.com, John Snow , qemu-block@nongnu.org, rjones@redhat.com, Jeff Cody , Markus Armbruster , stefanha@redhat.com, den@openvz.org, pbonzini@redhat.com, eblake@redhat.com Message-ID: <527aa7ab-3e62-90d9-3551-22036e2ce7fe@redhat.com> Subject: Re: [PATCH v8 00/36] block: Image locking series References: <1475237406-26917-1-git-send-email-famz@redhat.com> <20161024101111.GB4374@noname.redhat.com> <20161025082435.GA4695@noname.str.redhat.com> In-Reply-To: <20161025082435.GA4695@noname.str.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 25.10.2016 10:24, Kevin Wolf wrote: > Am 24.10.2016 um 20:03 hat Max Reitz geschrieben: >> On 24.10.2016 12:11, Kevin Wolf wrote: >> >> [...] >> >>> Now, the big question is how to translate this into file locking. Thi= s >>> could become a little tricky. I had a few thoughts involving another >>> lock on byte 2, but none of them actually worked out so far, because >>> what we want is essentially a lock that can be shared by readers, tha= t >>> can also be shared by writers, but not by readers and writers at the >>> same time. >> >> You can also share it between readers and writers, as long as everyone= >> can cope with volatile data. >=20 > Sorry, that was ambiguous. I meant a file-level lock rather than the > high-level one. If we had a lock that can be shared by one or the other= , > but not both, then two locks would be enough to build what we really > want. >=20 >> I agree that it's very similar to the proposed op blocker style, but I= >> can't really come up with a meaningful translation either. >> >> Maybe something like this (?): All readers who do not want the file to= >> be modified grab a shared lock on byte 1. All writers who can deal wit= h >> volatile data grab a shared lock on byte 2. Exclusive writers grab an >> exclusive lock on byte 1 and 2. Readers who can cope with volatile dat= a >> get no lock at all. >> >> When opening, the first and second group would always have to test >> whether there is a lock on the other byte, respectively. E.g. sharing >> writers would first grab an exclusive lock on byte 1, then the shared >> lock on byte 2 and then release the exclusive lock again. >> >> Would that work? >=20 > I'm afraid it wouldn't. If you start the sharing writer first and then > the writer-blocking reader, the writer doesn't hold a lock on byte 1 an= y > more, But it holds a lock on byte 2. > so the reader can start even though someone is writing to the > image. It can't because it would try to grab an exclusive lock on byte 2 before grabbing the shared lock on byte 1. Max > On the other hand, the writer can't keep an exclusive lock > because it would block other users that can share the image. >=20 > Kevin >=20 --NJgFhONrR99PsdAINqkK4u8SqKk5vPr07 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEvBAEBCAAZBQJYD16DEhxtcmVpdHpAcmVkaGF0LmNvbQAKCRD0B9sAYdXPQBh4 CACJkl2brIclPSReQ+qWoddI2p1ntzbhGi0Pp9SJ4VDb61TrCIPxoJzWqML5EkzN 5Pc4QjJGQIlhmeFSlJuy8RvR1ltUizEBSsZ5jXfRL/A3Z6XUdyul881OvvDv54wr Kwqbjs1sjF7V1mb9PqdwZ2QCSAIq483R2Q3OgQ94JaSfAjiJaYoJbdwScMim3TFh Zn4qUJzNvNL5iPRNUrLVhM7SgkTt+iayDoAzgKBvxk/ihnevZ6HapfS72NL8kOkr fx3+hkfoQgzf7n8gDI+xjVQ/uJhf0BfxGmCP6dAP6N4lz+dIVLVvQ6AiHaLqnM6N KjIYx30mPKnzo+Su3WZZd/H1 =m+Zc -----END PGP SIGNATURE----- --NJgFhONrR99PsdAINqkK4u8SqKk5vPr07--