From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROYvn-0003yB-PQ for qemu-devel@nongnu.org; Thu, 10 Nov 2011 13:00:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROYvk-0000GF-GS for qemu-devel@nongnu.org; Thu, 10 Nov 2011 13:00:55 -0500 Received: from mail-vx0-f173.google.com ([209.85.220.173]:65426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROYvk-0000Fz-E2 for qemu-devel@nongnu.org; Thu, 10 Nov 2011 13:00:52 -0500 Received: by vcbfo13 with SMTP id fo13so541434vcb.4 for ; Thu, 10 Nov 2011 10:00:51 -0800 (PST) Message-ID: <4EBC1150.6030106@codemonkey.ws> Date: Thu, 10 Nov 2011 12:00:48 -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: <4EBBAA5C.9010505@redhat.com> 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: Kevin Wolf Cc: Lucas Meneghel Rodrigues , KVM mailing list , "Michael S. Tsirkin" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira , Avi Kivity On 11/10/2011 04:41 AM, Kevin Wolf wrote: > Am 09.11.2011 22:01, schrieb Anthony Liguori: >> On 11/09/2011 03:00 PM, Michael S. Tsirkin wrote: >>> On Wed, Nov 09, 2011 at 02:22:02PM -0600, Anthony Liguori wrote: >>>> On 11/09/2011 02:18 PM, Michael S. Tsirkin wrote: >>>>> On Wed, Nov 09, 2011 at 11:35:54AM -0600, Anthony Liguori wrote: >>>>>> On 11/09/2011 11:02 AM, Avi Kivity wrote: >>>>>>> On 11/09/2011 06:39 PM, Anthony Liguori wrote: >>>>>>>> >>>>>>>> Migration with qcow2 is not a supported feature for 1.0. Migration is >>>>>>>> only supported with raw images using coherent shared storage[1]. >>>>>>>> >>>>>>>> [1] NFS is only coherent with close-to-open which right now is not >>>>>>>> good enough for migration. >>>>>>> >>>>>>> Say what? >>>>>> >>>>>> Due to block format probing, we read at least the first sector of >>>>>> the disk during start up. >>>>> >>>>> A simple solution is not to do any probing before the VM is first >>>>> started on the incoming path. >>>>> >>>>> Any issues with this? >>>>> >>>> >>>> http://mid.gmane.org/1284213896-12705-4-git-send-email-aliguori@us.ibm.com >>>> I think Kevin wanted open to get delayed. >>>> >>>> Regards, >>>> >>>> Anthony Liguori >>> >>> So, this patchset just needs to be revived and polished up? >> >> 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 don't think reopen is good enough without delaying CHS probing too. That information is still potentially out of date. I don't think you can fix this problem without delaying CHS probing at least. Regards, Anthony Liguori > > 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. > > Kevin >