From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NHbdK-0003X0-E9
	for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:20:02 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NHbdE-0003TW-NM
	for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:20:00 -0500
Received: from [199.232.76.173] (port=55453 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NHbdE-0003TI-9V
	for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:19:56 -0500
Received: from mail2.shareable.org ([80.68.89.115]:50793)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1NHbdD-00011K-Qu
	for qemu-devel@nongnu.org; Mon, 07 Dec 2009 06:19:56 -0500
Date: Mon, 7 Dec 2009 11:19:54 +0000
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks.
Message-ID: <20091207111953.GA29980@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>
	<20091207104517.GJ24530@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20091207104517.GJ24530@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: "Richard W.M. Jones" <rjones@redhat.com>, qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>

Daniel P. Berrange wrote:
> > 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?
> 
> Isn't this what Richard has already done ? The patch implements 'shared'
> as a 'F_RDLCK' lock and 'exclusive' as 'F_WRLCK':

No, the question is whether it makes sense to provide a 'shared'
option on the command line, or simply to always map:

     image opened read only => F_FDLCK
     image opened writable => F_WRLCK

and provide only a single command line option: 'lock'.

-- Jamie