From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHx0C-0003eK-GH for qemu-devel@nongnu.org; Tue, 08 Dec 2009 05:09:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHx07-0003U6-CV for qemu-devel@nongnu.org; Tue, 08 Dec 2009 05:09:03 -0500 Received: from [199.232.76.173] (port=34071 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHx07-0003Tf-7D for qemu-devel@nongnu.org; Tue, 08 Dec 2009 05:08:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49705) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHwhB-0001CL-HN for qemu-devel@nongnu.org; Tue, 08 Dec 2009 04:49:25 -0500 Message-ID: <4B1E20E1.5060703@redhat.com> Date: Tue, 08 Dec 2009 10:48:17 +0100 From: Kevin Wolf 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> <4B198D5B.5080803@codemonkey.ws> <4B1A98D9.7010408@redhat.com> <4B1A9C9F.5040705@codemonkey.ws> <20091207105855.GK23109@amd.home.annexia.org> <4B1D057F.9000708@codemonkey.ws> <20091207140857.GQ23109@amd.home.annexia.org> <4B1D0FA0.8060500@codemonkey.ws> <20091207143116.GR23109@amd.home.annexia.org> In-Reply-To: <20091207143116.GR23109@amd.home.annexia.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: Avi Kivity , qemu-devel@nongnu.org Am 07.12.2009 15:31, schrieb Richard W.M. Jones: > On Mon, Dec 07, 2009 at 08:22:24AM -0600, Anthony Liguori wrote: >> Richard W.M. Jones wrote: >>> On Mon, Dec 07, 2009 at 07:39:11AM -0600, Anthony Liguori wrote: >>> >>>> Richard W.M. Jones wrote: >>>> >>>>> Also if we only acquire the lock during the commit operation then >>>>> we'll end up with disk corruption. >>>>> >>>> Why do we end up with disk corruption? >>>> >>> >>> Forget about locking for a minute, I don't think this is safe >>> currently. If you have two VMs set up like: >>> >>> qemu-img create -b backing.img foo.img >>> qemu-img create -b backing.img bar.img >>> >>> qemu -drive file=foo.img # VM1 >>> qemu -drive file=bar.img # VM2 >>> >>> If VM1 does a commit to the backing image, then VM2 may be caching (in >>> its kernel memory) bits of the old backing image, and will >>> subsequently fetch bits of the new backing image, so it'll see a >>> mixture of old and new data. How is VM2 supposed to cope with this? >>> It sounds like massive disk corruption to me ... >>> >> >> Yes, this will cause corruption. Implementing locking in the fashion >> I've previously described will prevent 'commit' from being run (since >> you can't upgrade the lock since someone else is holding a read-lock). > > So to be clear, the use case is that all the other VMs must be shut > down, then the VM which wants to commit will upgrade its lock and > commit, and then all the other VMs will restart? I agree this should > avoid corruption, although it sounds like something which is fairly > unlikely to be done in practice. I can't see how the file system of VM2 could possibly survive if VM1 commits its changes. Even if VM2 or even both VMs are shut down while we're corrupting the base image. Basically, you must not commit to a backing file unless your COW file is the only user of this backing file. Kevin