From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NGbkX-0004Ct-AW
	for qemu-devel@nongnu.org; Fri, 04 Dec 2009 12:15:21 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NGbkS-0004B9-FM
	for qemu-devel@nongnu.org; Fri, 04 Dec 2009 12:15:20 -0500
Received: from [199.232.76.173] (port=56574 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NGbkS-0004B3-AU
	for qemu-devel@nongnu.org; Fri, 04 Dec 2009 12:15:16 -0500
Received: from mail-qy0-f194.google.com ([209.85.221.194]:54215)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NGbkS-0000FO-Ch
	for qemu-devel@nongnu.org; Fri, 04 Dec 2009 12:15:16 -0500
Received: by qyk32 with SMTP id 32so1096046qyk.4
	for <qemu-devel@nongnu.org>; Fri, 04 Dec 2009 09:15:15 -0800 (PST)
Message-ID: <4B1943A0.7030509@codemonkey.ws>
Date: Fri, 04 Dec 2009 11:15:12 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks.
References: <20091204165301.GA4167@amd.home.annexia.org>
In-Reply-To: <20091204165301.GA4167@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: <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: "Richard W.M. Jones" <rjones@redhat.com>
Cc: qemu-devel@nongnu.org

Richard W.M. Jones wrote:
> [from the commit message ...]
>
> Allow qemu to acquire shared and exclusive locks on disk images.
> This is done by extending the -drive option with an additional,
> optional parameter:
>
>   -drive [...],lock=none
>   -drive [...],lock=shared
>   -drive [...],lock=exclusive
>
> lock=none is the default, and it means that we don't try to acquire
> any sort of lock.
>
> lock=shared tries to acquire a shared lock on the disk image.
> Multiple instances of qemu may all hold this sort of lock.
>
> lock=exclusive tries to acquire an exclusive lock on the disk
> image.  An exclusive lock excludes all other shared and exclusive
> locks.
>
> If acquisition of a lock fails, opening the image fails.
>
> The implementation of locks only works for raw POSIX and Win32
> files.  However many of the other block types are implemented
> in terms of these drivers, so they "inherit" locking too.  Other
> drivers are read-only, so don't require locking.  Below we note
> only the cases where locking is *not* implemented:
>
>   cloop - directly open()s the file, no locking implemented
>   cow - same as cloop
>   curl - protocol probably doesn't support locking
>   nbd - same as curl
>   

The problem with something like this is that it gives a false sense of 
security.

You can still run into problems if you have an application accessing the 
image that doesn't attempt to acquire the lock.

Regards,

Anthony Liguori