From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byx2L-00049Z-4F for qemu-devel@nongnu.org; Tue, 25 Oct 2016 04:24:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byx2K-0006KL-Al for qemu-devel@nongnu.org; Tue, 25 Oct 2016 04:24:45 -0400 Date: Tue, 25 Oct 2016 10:24:35 +0200 From: Kevin Wolf Message-ID: <20161025082435.GA4695@noname.str.redhat.com> References: <1475237406-26917-1-git-send-email-famz@redhat.com> <20161024101111.GB4374@noname.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: 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: Max Reitz 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 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 24.10.2016 um 20:03 hat Max Reitz geschrieben: > On 24.10.2016 12:11, Kevin Wolf wrote: >=20 > [...] >=20 > > Now, the big question is how to translate this into file locking. This > > 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, that > > can also be shared by writers, but not by readers and writers at the > > same time. >=20 > You can also share it between readers and writers, as long as everyone > can cope with volatile data. 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. > 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. >=20 > 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 with > 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 data > get no lock at all. >=20 > 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. >=20 > Would that work? 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 any more, so the reader can start even though someone is writing to the image. On the other hand, the writer can't keep an exclusive lock because it would block other users that can share the image. Kevin --FCuugMFkClbJLl1L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYDxbDAAoJEH8JsnLIjy/WzNkQAKiJGgl66ozRrZ7GXALSQRST nFDRUjxrx2Jv8dfgMgCUK31h/z++I6VjKcj/VXH/1w4vECRMRjze8cL7DW7bIrNs yYWYUEHnXiwQ0nRW7qaTCKZ7oSVcy7I+bfu5dEysV4Pj1O9OxPnxX5SuLRf7R9jB fwVEn6HV4akKGnuLnS/LWTkYkIVfEikJwOr6D2vVbxxacuTj40olHwtlwRia3uLb 6Keft8YcAzhN5Nf1r6+FnvBcvahlztJrbBU+jmK15PX4pysHKzcGjC9ajI4YuvY1 7rbUzm2NVHoYFtBjKw3Retz+/uYjtJRFw4CrExPiIH0KbsCveI616jk1OMd3qHxR XixNdQQhLWESbLYH8aGCWVXsw8qVIMCCfeu26t9OFTRj5/ggDEdzZvwMp3vdJct/ oCkrz07olQ/mnnh/lNeh9rLF/TPnPpCBxB8NqDQrLyfnWSdA6/XRJqTy1vWtQkNo G02O2qR+cetnD754yLz8Fngs9R6xTPKo92zG/YfTPTYeUDJPfkFwFTt+v2JDKH22 HvV2kY/TMLjWWtSborRksuNARdjB+xp4DpAU4MUCe6moIvO+ZJo4EBsPj6PPDrtz PzKL00Pm4rWSbZKxMOL9cSKrXVPBvUkeaNsrji1EOO5tNVPddL6SxuRTfyaSMtUG wjVhZp0u89XBJTh4Jv1k =WVi7 -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L--