From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NGg9N-0007Ta-6v for qemu-devel@nongnu.org; Fri, 04 Dec 2009 16:57:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NGg9I-0007LL-9N for qemu-devel@nongnu.org; Fri, 04 Dec 2009 16:57:16 -0500 Received: from [199.232.76.173] (port=50171 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGg9H-0007L5-S2 for qemu-devel@nongnu.org; Fri, 04 Dec 2009 16:57:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:28071) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NGg9H-0000Cf-Dn for qemu-devel@nongnu.org; Fri, 04 Dec 2009 16:57:11 -0500 Date: Fri, 4 Dec 2009 21:57:07 +0000 From: "Richard W.M. Jones" Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks. Message-ID: <20091204215517.GA5938@amd.home.annexia.org> References: <20091204165301.GA4167@amd.home.annexia.org> <4B1943A0.7030509@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1943A0.7030509@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On Fri, Dec 04, 2009 at 11:15:12AM -0600, Anthony Liguori wrote: > 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. 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? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw