From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39146) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHuy6-0007cf-Gb for qemu-devel@nongnu.org; Tue, 19 Mar 2013 07:44:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHuy4-0004vN-Mf for qemu-devel@nongnu.org; Tue, 19 Mar 2013 07:44:38 -0400 Received: from mail.avalus.com ([2001:41c8:10:1dd::10]:38738) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHuy4-0004vF-GN for qemu-devel@nongnu.org; Tue, 19 Mar 2013 07:44:36 -0400 Date: Tue, 19 Mar 2013 11:44:22 +0000 From: Alex Bligh Message-ID: <45EC1ED73B198669B314A507@nimrod.local> In-Reply-To: <5148489C.70808@redhat.com> 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> <5148489C.70808@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [Qemu-devel] [Xen-devel] [PATCHv3] QEMU(upstream): Disable xen's use of O_DIRECT by default as it results in crashes. Reply-To: Alex Bligh List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , George Dunlap Cc: Ian Campbell , Stefano Stabellini , Alex Bligh , Ian Jackson , qemu-devel@nongnu.org, xen-devel , Anthony Liguori --On 19 March 2013 12:14:36 +0100 Paolo Bonzini wrote: > 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. If you closed the file and reopened it, then on NFS this would have this effect I believe, as it needs to check whether other clients have modified the file to give open/close coherency. However, we are rather assuming the file isn't even open at the point it is closed by the sender, which is what George is investigating. If this isn't true, we have a problem anyway with (e.g.) emulated devices which don't use O_DIRECT anyway. And I had thought (I may be wrong) using O_DIRECT does not guarantee no read caching with NFS; O_DIRECT merely guarantees the page cache is not used under Linux and isn't defined under POSIX: http://www.spinics.net/lists/linux-nfs/msg17472.html If it were just a write caching issue, we could use O_DSYNC instead of O_DIRECT, which would at least ensure the copy from userspace. -- Alex Bligh