From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHuVR-0005zl-9N for qemu-devel@nongnu.org; Tue, 19 Mar 2013 07:15:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHuVM-0002HT-Cq for qemu-devel@nongnu.org; Tue, 19 Mar 2013 07:15:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHuVM-0002HF-3c for qemu-devel@nongnu.org; Tue, 19 Mar 2013 07:14:56 -0400 Message-ID: <5148489C.70808@redhat.com> Date: Tue, 19 Mar 2013 12:14:36 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1363609123-20748-1-git-send-email-alex@alex.org.uk> <51471767.8030604@redhat.com> <7AC8953FE45335FB794B6DFE@Ximines.local> <51471F14.7030209@redhat.com> <6D0F4ACDA3B7FCF1A50F8B52@Ximines.local> <5147298C.8080900@redhat.com> <51473E82.1020806@redhat.com> <861AFE1A9C44444FD8BAEE16@Ximines.local> <5147512E.5050501@eu.citrix.com> <5147562E.1090203@redhat.com> <5148414C.7060303@redhat.com> <51484328.4030301@eu.citrix.com> In-Reply-To: <51484328.4030301@eu.citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] [PATCHv3] QEMU(upstream): Disable xen's use of O_DIRECT by default as it results in crashes. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: George Dunlap Cc: Ian Campbell , Stefano Stabellini , Ian Jackson , "qemu-devel@nongnu.org" , xen-devel , Alex Bligh , Anthony Liguori Il 19/03/2013 11:51, George Dunlap ha scritto: > On 03/19/2013 10:43 AM, Paolo Bonzini wrote: >>>> Even for successful migration, it would also be bad for downtime (QEMU >>>> isn't exactly lightning-fast to start). And even if failure weren't >>>> catastrophic, it would be a pity to transfer a few gigs of memory and >>>> then find out that QEMU isn't present in the destination. :) >>> >>> Well, if qemu isn't present at the destination, that's definitely user >>> error. :-) In any case, I know that he migrate can resume if it >>> fails, so I suspect that the qemu is just paused on the sending side >>> until the migration is known to complete. As long as the last write >>> was flushed to the NFS server before the receiver opens the file, we >>> should be safe. >> >> Note that the close really must happen before the next open. Otherwise >> the file metadata might not be up-to-date on the destination, too. > > By "file metadata" I assume you mean "metadata about the virtual disk > within the file", not "metadata about the file within the filesystem", > right? That's good to know, I'll keep that in mind. Actually especially the former (I'm calling them respectively "image metadata" and "file metadata"). File metadata could also be a problem, but I think it might just work except in cases like on-line resizing during migration. > Even if it's true that at the moment qemu doesn't write the file > metadata until it closes the file, that just means we'd have to add a > hook to the callback to save qemu state, to sync the metadata at that > point, right? Unfortunately no. The problem is in the loading side's kernel, on which you do not have any control. If the loading side doesn't use O_DIRECT, any attempt to invalidate the metadata in userspace or on the source is futile, because there is no way to invalidate the page cache's copy of that metadata. Paolo