From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34369) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz3Ak-0006Mr-Jy for qemu-devel@nongnu.org; Tue, 25 Oct 2016 10:57:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz3Aj-000060-PN for qemu-devel@nongnu.org; Tue, 25 Oct 2016 10:57:50 -0400 Date: Tue, 25 Oct 2016 16:57:39 +0200 From: Kevin Wolf Message-ID: <20161025145739.GL4695@noname.str.redhat.com> References: <1475237406-26917-1-git-send-email-famz@redhat.com> <20161024101111.GB4374@noname.redhat.com> <20161025082435.GA4695@noname.str.redhat.com> <527aa7ab-3e62-90d9-3551-22036e2ce7fe@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline In-Reply-To: <527aa7ab-3e62-90d9-3551-22036e2ce7fe@redhat.com> 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 --7iMSBzlTiPOCCT2k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 25.10.2016 um 15:30 hat Max Reitz geschrieben: > 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. 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. > >> > >> 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 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. > >> > >> 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 any > > more, >=20 > But it holds a lock on byte 2. >=20 > > so the reader can start even though someone is writing to the > > image. >=20 > It can't because it would try to grab an exclusive lock on byte 2 before > grabbing the shared lock on byte 1. Apparently I failed to understand the most important part of the proposal. :-) So we have two locks. Both are only held for a longer time in shared mode. Exclusive mode is only used for testing whether the lock is being held and is immediately given up again. The meaning of holding a shared lock is: byte 1: I can't allow other processes to write to the image byte 2: I am writing to the image The four cases that we have involve: * shared writer: Take shared lock on byte 2. Test whether byte 1 is locked using an exclusive lock, and fail if so. * exclusive writer: Take shared lock on byte 2. Test whether byte 1 is locked using an exclusive lock, and fail if so. Then take shared lock on byte 1. I suppose this is racy, but we can probably tolerate that. * reader that can tolerate writers: Don't do anything * reader that can't tolerate writers: Take shared lock on byte 1. Test whether byte 2 is locked, and fail if so. Seems to work if I got that right. Kevin --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYD3LiAAoJEH8JsnLIjy/WnvAP/3aoVQXaks+e1kLJ4HZ6/mxo xxSdQz2zOFxjsJSmPP7FsRVX6a7MRHAn2sQokyo3S9aMPHsXjC5ijU0kQsujVj/E EZB8nyfhyASuPL/ch+1M/big0RPralvnGic/jGMh3Pfdc1IeKZBM1K1dM0okY7Ol PV9L73GBbIJXRU5EHL/IkVuWW1wFv2432a/Tl80DJiWEx/c2Ziu/EEhOAbi7IbQ5 3g/AgH2cRzgbDd3WlEG9fbrHIFGIR3UP5L+REM6sktFn7S2yrw+GyAsIWaTJ9w5X TdfkYdr1YzzmpCZgb+T+dJx+I1CleUNZV9vu2ImI8ivehXWO/KP/g1Fc41u1GLl7 H/dm9g2Vk/f83vJS+imp7QZzkLTR7ppMUcwk9ck3r+sQ6aOBz2lCJ+gTrsS5qmKW Bu8BlK4ntdPB+rTpbgW9dzHC7/g6u+tst/xAqHPOHEzoyWAJuyO/KzRYTV94rTXy KySO85FOXZTkpQdeE2XjrVT+DfPzqr0yZ7SjaSF0vzznxu+uGEfYZeUsX59Nuy0T lHpAHAygzRq/03L8O6hqPZpOMUKKZ30v8XE6NtGS7nldQiwKpvUtldZcU5Cpfak2 MiXGZPyPhcgGOVxCVYpkvmSQJwX3NRp9391s+JV+sbe/AgZbHULDe58iih4wFfLs pod3q5O+bLIob0LOo4r3 =C8yR -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k--