From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHblj-0007fG-AJ for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:28:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHble-0007da-SM for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:28:42 -0500 Received: from [199.232.76.173] (port=54153 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHble-0007dQ-IX for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:28:38 -0500 Received: from mail2.shareable.org ([80.68.89.115]:39802) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NHblb-0001jT-Q8 for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:28:38 -0500 Date: Mon, 7 Dec 2009 11:28:34 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks. Message-ID: <20091207112834.GB29980@shareable.org> 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> <4B1CDC1F.9000705@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1CDC1F.9000705@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: "Richard W.M. Jones" , qemu-devel@nongnu.org, Avi Kivity Kevin Wolf wrote: > Am 07.12.2009 11:31, schrieb Jamie Lokier: > > 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? > > I think there are people using shared writable images with cluster file > systems. Yes, they are. Please the following again: > > 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. If you run each guest in the disk-sharing cluster with 'lock=shared', it reflects that they are sharing - but that doesn't actually prevent mistakes, does it? If you run any of those guests a second time, it won't prevent that. So what's the point in the shared lock? Same when you have guests sharing a partitioned disk, with each guest accessing a different partition. E.g. a Windows/Linux dual boot, and you decide to run both guest OSes at the same time as they should be fine. You'd have to use 'lock=shared' - and when you do that, it doesn't protect you against running them again by accident. In all those cases you need locking at a higher level to be effective at stopping the wrong guests from being invoked simultaneously. So - can anyone think of a situation where being able to ask for a shared lock on an image opened for writing is useful? -- Jamie