From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROYuC-0002le-2u for qemu-devel@nongnu.org; Thu, 10 Nov 2011 12:59:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROYuA-0008US-9U for qemu-devel@nongnu.org; Thu, 10 Nov 2011 12:59:15 -0500 Received: from mail-qw0-f45.google.com ([209.85.216.45]:51051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROYuA-0008UO-65 for qemu-devel@nongnu.org; Thu, 10 Nov 2011 12:59:14 -0500 Received: by qadz3 with SMTP id z3so3786066qad.4 for ; Thu, 10 Nov 2011 09:59:13 -0800 (PST) Message-ID: <4EBC10EE.1010701@codemonkey.ws> Date: Thu, 10 Nov 2011 11:59:10 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws> <4EBAB236.2060409@redhat.com> <4EBAB9FA.3070601@codemonkey.ws> <20111109201836.GA28457@redhat.com> <4EBAE0EA.1030405@codemonkey.ws> <20111109210052.GB28599@redhat.com> <4EBAEA33.9090709@codemonkey.ws> <4EBBAA5C.9010505@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: Kevin Wolf , Lucas Meneghel Rodrigues , KVM mailing list , "Michael S. Tsirkin" , Marcelo Tosatti , QEMU devel , Avi Kivity On 11/10/2011 10:50 AM, Juan Quintela wrote: > Kevin Wolf wrote: > >>> What I took from the feedback was that Kevin wanted to defer open until the >>> device model started. That eliminates the need to reopen or have a invalidation >>> callback. >>> >>> I think it would be good for Kevin to comment here though because I might have >>> misunderstood his feedback. >> >> Your approach was to delay reads, but still keep the image open. I think >> I worried that we might have additional reads somewhere that we don't >> know about, and this is why I proposed delaying the open as well, so >> that any read would always fail. >> >> I believe just reopening the image is (almost?) as good and it's way >> easier to do, so I would be inclined to do that for 1.0. >> >> I'm not 100% sure about cases like iscsi, where reopening doesn't help. >> I think delaying the open doesn't help there either if you migrate from >> A to B and then back from B to A, you could still get old data. So for >> iscsi probably cache=none remains the only safe choice, whatever we do. > > iSCSI and NFS only works with cache=none. Even on NFS with close+open, > we have troubles if anything else has the file opened (think libvirt, > guestfs, whatever). Reopening with iSCSI is strictly an issue with the in-kernel initiator, right? libiscsi should be safe with a delayed open I would imagine. Regards, Anthony Liguori I really think that anynthing different of > cache=none from iSCSI or NFS is just betting (and yes, it took a while > for Christoph to convince me, I was trying to a "poor man" distributed > lock manager, and as everybody knows, it is a _difficult_ problem to > solve.). > > Later, Juan. >