From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHasU-0001Gt-Em for qemu-devel@nongnu.org; Mon, 07 Dec 2009 05:31:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHasP-000191-E5 for qemu-devel@nongnu.org; Mon, 07 Dec 2009 05:31:37 -0500 Received: from [199.232.76.173] (port=52346 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHasO-00018h-Vn for qemu-devel@nongnu.org; Mon, 07 Dec 2009 05:31:33 -0500 Received: from mail2.shareable.org ([80.68.89.115]:40037) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NHasO-0005rQ-Jl for qemu-devel@nongnu.org; Mon, 07 Dec 2009 05:31:32 -0500 Date: Mon, 7 Dec 2009 10:31:28 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks. Message-ID: <20091207103128.GA26970@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1A9F8C.3010106@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Avi Kivity , "Richard W.M. Jones" 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? -- Jamie