From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f44.google.com ([209.85.218.44]:33984 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750887AbcFXBOs (ORCPT ); Thu, 23 Jun 2016 21:14:48 -0400 Received: by mail-oi0-f44.google.com with SMTP id s66so95837486oif.1 for ; Thu, 23 Jun 2016 18:14:48 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160623232446.GA12670@dastard> References: <1466609236-23801-1-git-send-email-hch@lst.de> <20160623232446.GA12670@dastard> From: Dan Williams Date: Thu, 23 Jun 2016 18:14:47 -0700 Message-ID: Subject: Re: xfs: untangle the direct I/O and DAX path, fix DAX locking To: Dave Chinner Cc: Christoph Hellwig , linux-fsdevel , linux-nvdimm , XFS Developers Content-Type: text/plain; charset=UTF-8 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Jun 23, 2016 at 4:24 PM, Dave Chinner wrote: > On Wed, Jun 22, 2016 at 05:27:08PM +0200, Christoph Hellwig wrote: >> The last patch is what started the series: XFS currently uses the >> direct I/O locking strategy for DAX because DAX was overloaded onto >> the direct I/O path. For XFS this means that we only take a shared >> inode lock instead of the normal exclusive one for writes IFF they >> are properly aligned. While this is fine for O_DIRECT which requires >> explicit opt-in from the application it's not fine for DAX where we'll >> suddenly lose expected and required synchronization of the file system >> happens to use DAX undeneath. > > Except we did that *intentionally* - by definition there is no > cache to bypass with DAX and so all IO is "direct". That, combined > with the fact that all Linux filesystems except XFS break the POSIX > exclusive writer rule you are quoting to begin with, it seemed > pointless to enforce it for DAX.... If we're going to be strict about POSIX fsync() semantics we should be strict about this exclusive write semantic. In other words why is it ok to loosen one and not the other, if application compatibility is the concern? > > So, before taking any patches to change that behaviour in XFS, a > wider discussion about the policy needs to be had. I don't think > we should care about POSIX here - if you have an application that > needs this serialisation, turn off DAX. s/needs this serialisation/needs the kernel to flush cpu cache/