From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755783AbbKEUyY (ORCPT ); Thu, 5 Nov 2015 15:54:24 -0500 Received: from mail-io0-f180.google.com ([209.85.223.180]:35978 "EHLO mail-io0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752100AbbKEUyV (ORCPT ); Thu, 5 Nov 2015 15:54:21 -0500 Subject: Re: [RFC 00/11] DAX fsynx/msync support To: Dave Chinner , Jeff Moyer References: <1446149535-16200-1-git-send-email-ross.zwisler@linux.intel.com> <20151030035533.GU19199@dastard> <20151030183938.GC24643@linux.intel.com> <20151101232948.GF10656@dastard> <20151102201029.GI10656@dastard> <20151105083309.GJ19199@dastard> Cc: Ross Zwisler , linux-kernel@vger.kernel.org, "H. Peter Anvin" , "J. Bruce Fields" , "Theodore Ts'o" , Alexander Viro , Andreas Dilger , Dan Williams , Ingo Molnar , Jan Kara , Jeff Layton , Matthew Wilcox , Thomas Gleixner , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@ml01.01.org, x86@kernel.org, xfs@oss.sgi.com, Andrew Morton , Matthew Wilcox From: Jens Axboe Message-ID: <563BC1FB.60004@kernel.dk> Date: Thu, 5 Nov 2015 13:54:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151105083309.GJ19199@dastard> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/05/2015 01:33 AM, Dave Chinner wrote: >> Des xfs rely on this model for correctness? If so, I'd say we've got a >> problem > > No, it doesn't. The XFS integrity model doesn't trust the IO layers > to tell the truth about IO ordering and completion or for it's > developers to fully understand how IO layer ordering works. :P That's good, because the storage developers simplified the model so that fs developers would be able to get and use it. > i.e. we wait for full completions of all dependent IO before issuing > flushes or log writes that use REQ_FLUSH|REQ_FUA semantics to ensure > the dependent IOs are fully caught by the cache flushes... ... which is what you are supposed to do, that's how it works. -- Jens Axboe