From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHbvi-0006pj-Ez for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:39:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHbvd-0006li-3Y for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:39:01 -0500 Received: from [199.232.76.173] (port=48193 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHbvc-0006lX-SH for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:38:56 -0500 Received: from mail2.shareable.org ([80.68.89.115]:35494) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NHbvc-0002Xk-8H for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:38:56 -0500 Date: Mon, 7 Dec 2009 11:38:54 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks. Message-ID: <20091207113854.GD29980@shareable.org> References: <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> <20091207113147.GO23109@amd.home.annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091207113147.GO23109@amd.home.annexia.org> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: qemu-devel@nongnu.org, Avi Kivity Richard W.M. Jones wrote: > > 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. Exactly. Shared locks are only useful if you have an exclusive locker to protect against, and in the case of a shared-disk cluster, there isn't one. Except, perhaps, some admin tools when the cluster is down. That said, with shared partitioned disk images, it could be useful to exclusively lock the individual partitions. I think by then we're involving a tool outside qemu, so it can take the lock itself. That's a reason why qemu's F_WRLOCK should cover the whole range of file offsets, not just say the first byte. -- Jamie