From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHbor-00011K-5x for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:31:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHbom-0000wt-3D for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:31:56 -0500 Received: from [199.232.76.173] (port=40492 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHbol-0000wi-RR for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:31:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:28882) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHbol-0001zs-B4 for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:31:51 -0500 Date: Mon, 7 Dec 2009 11:31:47 +0000 From: "Richard W.M. Jones" Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks. Message-ID: <20091207113147.GO23109@amd.home.annexia.org> References: <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> <20091207104517.GJ24530@redhat.com> <20091207111953.GA29980@shareable.org> <20091207113014.GK24530@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091207113014.GK24530@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, Avi Kivity On Mon, Dec 07, 2009 at 11:30:14AM +0000, Daniel P. Berrange wrote: > On Mon, Dec 07, 2009 at 11:19:54AM +0000, Jamie Lokier wrote: > > Daniel P. Berrange wrote: > > > > 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': > > > > No, the question is whether it makes sense to provide a 'shared' > > option on the command line, or simply to always map: > > > > image opened read only => F_FDLCK > > image opened writable => F_WRLCK > > > > and provide only a single command line option: 'lock'. > > That doesn't work in the case of setting up a clustered filesystem > shared between guests. That requires that the disk be opened writable, > but with a shared (F_RDLOCK) lock. I think Jamie's point is that you might as well use no locking at all in this configuration. It's hard to see what lock=shared is protecting you against. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v