From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHa3Q-0000VX-Ty for qemu-devel@nongnu.org; Mon, 07 Dec 2009 04:38:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHa3L-0000TM-Uk for qemu-devel@nongnu.org; Mon, 07 Dec 2009 04:38:52 -0500 Received: from [199.232.76.173] (port=43035 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHa3L-0000TD-Rm for qemu-devel@nongnu.org; Mon, 07 Dec 2009 04:38:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53600) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHa3L-0001Wq-Ff for qemu-devel@nongnu.org; Mon, 07 Dec 2009 04:38:47 -0500 Date: Mon, 7 Dec 2009 09:38:42 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks. Message-ID: <20091207093842.GC24530@redhat.com> 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> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "Richard W.M. Jones" , 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 same is true of any UNIX application that uses POSIX locking, but that doesn't mean they should not bother to use locking. POSIX advisory locking relies on applications to play nicely together. If management applications using QEMU take advantage of this functionality then it will provide a useful level of protection within a host, and (depending on the type of disk storage) may also provide protection between hosts. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|