From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHfAC-0001GK-8F for qemu-devel@nongnu.org; Mon, 07 Dec 2009 10:06:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHfA7-0001AH-HM for qemu-devel@nongnu.org; Mon, 07 Dec 2009 10:06:11 -0500 Received: from [199.232.76.173] (port=60185 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHfA7-00019y-5y for qemu-devel@nongnu.org; Mon, 07 Dec 2009 10:06:07 -0500 Received: from qw-out-1920.google.com ([74.125.92.146]:47688) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHfA7-0007Ku-7m for qemu-devel@nongnu.org; Mon, 07 Dec 2009 10:06:07 -0500 Received: by qw-out-1920.google.com with SMTP id 14so612499qwa.4 for ; Mon, 07 Dec 2009 07:06:06 -0800 (PST) Message-ID: <4B1D19D9.8080808@codemonkey.ws> Date: Mon, 07 Dec 2009 09:06:01 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH VERSION 2] Disk image shared and exclusive locks. References: <20091204165301.GA4167@amd.home.annexia.org> <20091207141652.GA28705@amd.home.annexia.org> In-Reply-To: <20091207141652.GA28705@amd.home.annexia.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Richard W.M. Jones wrote: > Here's a second go at this patch. The only change is that we add a > second parameter (backinglock=none|shared|exclusive) which can be used > to control locking on the first level (only) of backing disk. > > Dan Berrange convinced me there was a case to retain a distinct shared > locking type. > > For any qemu instance which is going to use the "commit" command, I > would advise using: lock=exclusive,backinglock=exclusive. > > For qemu instances which won't be using commit, I would advise: > lock=exclusive,backinglock=shared. > ETOOCOMPLEX So the situation we're trying to support is: 1) something grabs exclusive (but why would it?) 2) we want to still be able to run things as shared The alternative would be that we only provide lock=on|off. For GPFS-like shared filesystems (:-P) we would always use lock=off. It wouldn't protect us from a non-cluster aware writer. I assume libguestfs is the user of exclusive. However, wouldn't it be reasonable for libguestfs to want to be able to mount the GPFS volume and manipulate it? Why wouldn't libguestfs want to also use lock=shared | lock=off in this case? I think this is a knob you have to expose to your users. I think that also means that shared/exclusive is not so useful. Regards, Anthony Liguori