From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHeNb-00015p-Tl for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:16:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHeNW-00014f-3f for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:15:58 -0500 Received: from [199.232.76.173] (port=47257 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHeNV-00014c-UU for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:15:53 -0500 Received: from qw-out-1920.google.com ([74.125.92.145]:7656) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHeNW-0001LH-1O for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:15:54 -0500 Received: by qw-out-1920.google.com with SMTP id 14so603528qwa.4 for ; Mon, 07 Dec 2009 06:15:53 -0800 (PST) Message-ID: <4B1D0E17.7040507@codemonkey.ws> Date: Mon, 07 Dec 2009 08:15:51 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks. 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> <20091207140132.GN24530@redhat.com> In-Reply-To: <20091207140132.GN24530@redhat.com> 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: "Daniel P. Berrange" Cc: "Richard W.M. Jones" , qemu-devel@nongnu.org, Avi Kivity Daniel P. Berrange wrote: >> 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. The 3rd instance is getting data corruption. The corruption is transient because we're using -snapshot but if you change the scenario to use a persistent cow overlay, then the corruption is permanent. The semantics of shared/exclusive are non-obvious to anything but someone who understands the implementation. > '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. > I don't understand why it isn't safe to temporarily acquire a write lock with commit. Can you give an example of how it would cause corruption? Regards, Anthony Liguori > Daniel >