From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NGgf2-0006HG-5e
	for qemu-devel@nongnu.org; Fri, 04 Dec 2009 17:30:00 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NGgex-0006CP-HD
	for qemu-devel@nongnu.org; Fri, 04 Dec 2009 17:29:59 -0500
Received: from [199.232.76.173] (port=41122 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NGgex-0006CD-59
	for qemu-devel@nongnu.org; Fri, 04 Dec 2009 17:29:55 -0500
Received: from mail-yw0-f183.google.com ([209.85.211.183]:39258)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NGgew-0003Df-VK
	for qemu-devel@nongnu.org; Fri, 04 Dec 2009 17:29:55 -0500
Received: by ywh13 with SMTP id 13so3019982ywh.29
	for <qemu-devel@nongnu.org>; Fri, 04 Dec 2009 14:29:50 -0800 (PST)
Message-ID: <4B198D5B.5080803@codemonkey.ws>
Date: Fri, 04 Dec 2009 16:29:47 -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>
	<4B1943A0.7030509@codemonkey.ws>
	<20091204215517.GA5938@amd.home.annexia.org>
In-Reply-To: <20091204215517.GA5938@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:
> The idea would be for management tools (eg. libvirt) to add the lock
> parameter for all virtual machines that they manage.
>
> I don't see how this is worse than what we have now -- ie. no
> possibility of locking at all and a very real risk of disk corruption.
>
> Anyway, we could make the locking mandatory.  I believe that the
> locking under Win32 (using LockFileEx) is already mandatory.  With
> mandatory locks it would be pretty watertight in the single node case.
> Alternatively how about making lock=exclusive the default?
>   

Well disk sharing isn't actually bad as long as it's raw or a physical 
device.

For qcow2, it's very complicated by backing files because we really need 
to express the concept of a read-write lock.

That is, as long as the guests are opening the file read only, you 
should allow many readers.  However, you should prevent anyone from 
opening with write permission.  Likewise, writes should prevent future 
reads.

Regards,

Anthony Liguori