From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHdo7-0002xg-K8 for qemu-devel@nongnu.org; Mon, 07 Dec 2009 08:39:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHdo2-0002sB-SZ for qemu-devel@nongnu.org; Mon, 07 Dec 2009 08:39:19 -0500 Received: from [199.232.76.173] (port=52497 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHdo2-0002rx-Jy for qemu-devel@nongnu.org; Mon, 07 Dec 2009 08:39:14 -0500 Received: from mail-iw0-f197.google.com ([209.85.223.197]:34688) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHdo2-0006Dm-H6 for qemu-devel@nongnu.org; Mon, 07 Dec 2009 08:39:14 -0500 Received: by iwn35 with SMTP id 35so3039712iwn.4 for ; Mon, 07 Dec 2009 05:39:13 -0800 (PST) Message-ID: <4B1D057F.9000708@codemonkey.ws> Date: Mon, 07 Dec 2009 07:39:11 -0600 From: Anthony Liguori 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> In-Reply-To: <20091207105855.GK23109@amd.home.annexia.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 Richard W.M. Jones wrote: > On Sat, Dec 05, 2009 at 11:47:11AM -0600, Anthony Liguori wrote: > >> I think I made my point poorly. Consider the following: >> >> qemu-img create -f raw base.img 10G >> qemu-img create -f qcow2 -b base.img cow1.img >> qemu-img create -f qcow2 -b base.img cow2.img >> >> qemu -drive file=cow1.img,lock=exclusive >> qemu -drive file=cow2.img,lock=exclusive >> >> With the current patch, the second command will fail and it's impossible >> to invoke correctly. That's because flags are passed down to backing >> devices directly. >> > > Isn't it correct that the second command fails? Although the base > image is mostly used read-only, if the user does the "commit" command > in the monitor then the backing image is overwritten. (That's my > understanding of the documentation anyway - I've never actually used > this feature of qcow2). > That's a use-case that needs to be thought through. Maybe commit should attempt to force the lower level to acquire a write lock first? The above use-case is extremely common so it's something that's worth supporting. > 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? If someone else has the backing file open with a read lock, we won't be able to acquire the write lock. Once we've acquired the write lock, no one can acquire the read lock. Once we've released the write lock (after an fsync of course), we won't touch it again. Regards, Anthony Liguori