From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHxGS-0006iZ-Ku for qemu-devel@nongnu.org; Tue, 08 Dec 2009 05:25:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHxGO-0006g2-6y for qemu-devel@nongnu.org; Tue, 08 Dec 2009 05:25:52 -0500 Received: from [199.232.76.173] (port=57231 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHxGO-0006fz-0f for qemu-devel@nongnu.org; Tue, 08 Dec 2009 05:25:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44645) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHxGN-0005s1-N7 for qemu-devel@nongnu.org; Tue, 08 Dec 2009 05:25:47 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nB8APkmW018995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Dec 2009 05:25:47 -0500 Date: Tue, 8 Dec 2009 10:25:33 +0000 From: "Richard W.M. Jones" Subject: Re: [Qemu-devel] [PATCH VERSION 2] Disk image shared and exclusive locks. Message-ID: <20091208102533.GA28820@amd.home.annexia.org> References: <20091204165301.GA4167@amd.home.annexia.org> <20091207141652.GA28705@amd.home.annexia.org> <4B1E23B1.9040504@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1E23B1.9040504@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org On Tue, Dec 08, 2009 at 11:00:17AM +0100, Kevin Wolf wrote: > Am 07.12.2009 15:16, schrieb Richard W.M. Jones: > > Here's a second go at this patch. The only change is that we add a > > second parameter (backinglock=none|shared|exclusive) which can be used > > to control locking on the first level (only) of backing disk. > > And what about the backing file of the backing file? ;-) This approach > feels wrong somehow. I was under the impression that the grandparent backing file is never written to (eg. by commit or whatever), and so no locking would be required. That's why the backinglock doesn't get inherited recursively, and I checked that too. However maybe since it is being read, we should acquire shared locks for grandparent and above. > We need to infer the locking for backing file from the COW file > (none => none; shared/exclusive => shared; commit acquires an > exclusive lock temporarily, but still can't prevent corruption with > turned off VMs) > > You probably should add the locking flags to bdrv_open calls in > qemu-img, too. OK. 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