From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NGyv7-000537-Il for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:59:49 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NGyv1-0004xP-Sv for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:59:49 -0500 Received: from [199.232.76.173] (port=48068 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGyv1-0004xF-Nn for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:59:43 -0500 Received: from mail-gx0-f223.google.com ([209.85.217.223]:58532) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NGyv1-0001sV-Mo for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:59:43 -0500 Received: by gxk23 with SMTP id 23so719131gxk.2 for ; Sat, 05 Dec 2009 09:59:42 -0800 (PST) Message-ID: <4B1A9F8C.3010106@codemonkey.ws> Date: Sat, 05 Dec 2009 11:59:40 -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> <4B1A9E83.2050103@redhat.com> In-Reply-To: <4B1A9E83.2050103@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "Richard W.M. Jones" , qemu-devel@nongnu.org Avi Kivity 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. You really need to be much smarter here >> in how you handle locking. > > Oh, that's just an implementation bug. Obviously there's no need to > open a file for exclusive access if it will only be accessed for read > (when merging a snapshot we'd need to upgrade the lock to exclusive > while that takes place). I thought you objected to the whole concept. I'm not sure whether it's best to enable it by default because, as I said earlier, I'm not comfortable with the lack of correctness wrt advisory vs. mandatory locking. Only qemu can implement this level of locking though so it's definitely something we ought to support. However, from a UI and implementation perspective, I think we need significantly different semantics. You either want locking or you don't. I don't think the selection of none|shared|exclusive really makes sense. Regards, Anthony Liguori