From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHc9V-0007C0-Td for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:53:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHc9O-00075P-Qu for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:53:15 -0500 Received: from [199.232.76.173] (port=55270 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHc9O-00075E-Ht for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:53:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59186) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHc9N-0003YE-Uc for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:53:10 -0500 Message-ID: <4B1CEC5F.5050303@redhat.com> Date: Mon, 07 Dec 2009 12:51:59 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks. 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> <20091207112834.GB29980@shareable.org> In-Reply-To: <20091207112834.GB29980@shareable.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Am 07.12.2009 12:28, schrieb Jamie Lokier: > 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? Sorry, I apparently misunderstood. I was thinking about shared vs. exclusive whereas you are talking about shared vs. none (vs. something completely different). I think you're right there. Kevin