From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHb5p-0002Rz-SR for qemu-devel@nongnu.org; Mon, 07 Dec 2009 05:45:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHb5l-0002PM-TK for qemu-devel@nongnu.org; Mon, 07 Dec 2009 05:45:25 -0500 Received: from [199.232.76.173] (port=34358 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHb5l-0002PA-HY for qemu-devel@nongnu.org; Mon, 07 Dec 2009 05:45:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51523) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHb5l-0006mS-1O for qemu-devel@nongnu.org; Mon, 07 Dec 2009 05:45:21 -0500 Date: Mon, 7 Dec 2009 10:45:17 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks. Message-ID: <20091207104517.GJ24530@redhat.com> References: <20091204165301.GA4167@amd.home.annexia.org> <4B1943A0.7030509@codemonkey.ws> <20091204215517.GA5938@amd.home.annexia.org> <4B198D5B.5080803@codemonkey.ws> <4B1A98D9.7010408@redhat.com> <4B1A9C9F.5040705@codemonkey.ws> <4B1A9E83.2050103@redhat.com> <4B1A9F8C.3010106@codemonkey.ws> <20091207103128.GA26970@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091207103128.GA26970@shareable.org> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: "Richard W.M. Jones" , qemu-devel@nongnu.org, Avi Kivity On Mon, Dec 07, 2009 at 10:31:28AM +0000, Jamie Lokier wrote: > Anthony Liguori wrote: > > I'm not sure whether it's best to enable it by default because, as I > > said earlier, I'm not comfortable with the lack of correctness wrt > > advisory vs. mandatory locking. > > In my experience, disk images are accessed in one of five ways: > > qemu-img > qemu > qemu-nbd > mount -o loop > cp/rsync > > If all but the last implement qemu's advisory locking, that's comforting. > > > Only qemu can implement this level of locking though so it's > > definitely something we ought to support. > > That's not quite true. I have management scripts which call qemu-img > to determine the chain of backing images, and then can lock the chain. > (They determine the chain anyway, to provide reliable behaviour with > image names containing unusual characters and the old monitor, by > creating links with sane names in /tmp to the real files.) > > But it's a lot nicer if qemu does it. > > > However, from a UI and implementation perspective, I think we need > > significantly different semantics. You either want locking or you > > don't. I don't think the selection of none|shared|exclusive really > > makes sense. > > Sometimes shared access to a raw image (partitioned or whole disk > filesystem) is ok, and sometimes it is not ok. Only the user knows > the difference, because only the user knows if the guests they are > running use distinct partitions in the same raw image, or cooperative > access to a shard image. > > But does it make sense to request a shared lock in that case? Not > really. If you have a group of guests correctly sharing an image, you > still want to prevent running the same group a second time - and a > shared lock wouldn't do that, because each group would be requesting > shared locks. > > So the distinction read/write makes more sense. Can anyone think of a > situation where a shared lock on an image opened for writing is useful? Isn't this what Richard has already done ? The patch implements 'shared' as a 'F_RDLCK' lock and 'exclusive' as 'F_WRLCK': + if (bdrv_flags & BDRV_O_LOCK_SHARED) + lk.l_type = F_RDLCK; + else /* bdrv_flags & BDRV_O_LOCK_EXCLUSIVE */ + lk.l_type = F_WRLCK; It seems we're just debating different terminology for the same thing. Indeed the fcntl() man page uses read/write and shared/exclusive interchangably too The l_type field can be used to place a read (F_RDLCK) or a write (F_WRLCK) lock on a file. Any number of processes may hold a read lock (shared lock) on a file region, but only one process may hold a write lock (exclusive lock). An exclusive lock excludes all other locks, both shared and exclusive. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|