From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHe9o-0004hY-SS for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:01:44 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHe9k-0004e6-BJ for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:01:44 -0500 Received: from [199.232.76.173] (port=34149 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHe9j-0004dl-IH for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:01:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39964) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHe9j-00080p-9E for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:01:39 -0500 Date: Mon, 7 Dec 2009 14:01:32 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks. Message-ID: <20091207140132.GN24530@redhat.com> References: <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> <20091207111953.GA29980@shareable.org> <20091207113014.GK24530@redhat.com> <4B1D0699.4070402@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1D0699.4070402@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, Avi Kivity On Mon, Dec 07, 2009 at 07:43:53AM -0600, Anthony Liguori wrote: > Daniel P. Berrange wrote: > >That doesn't work in the case of setting up a clustered filesystem > >shared between guests. That requires that the disk be opened writable, > >but with a shared (F_RDLOCK) lock. > > > > If you'd like data corruption :-) > > qemu -drive file=/dev/hda,lock=shared # clustered file system > qemu -drive file=/dev/hda,lock=shared # clustered file system > > qemu -drive file=/dev/hda,lock=shared -snapshot # i have no awareness > of the last two. > > The 3rd invocation is totally fine. /dev/hda is shared (but the > expectation is read-only). > Better to stick with on/off. That gives much easier to understand > semantics. The 3rd invocation is not changing the backing file, so it is not causing data corruption on the master file. Sure the 3rd OS instance will probably crash & get confused because its backing file is changing under its feet but as long as 'commit' isn't used, it is still safe. 'commit' should require that the disk have been locked in exclusive mode from the time it started. It is not safe to merely let it upgrade the lock from shared to exclusive at time of committing because of this exact scenario. 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 :|