From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 11 Aug 2017 12:44:29 +0200 From: Christoph Hellwig To: Dan Williams Cc: Christoph Hellwig , "Darrick J. Wong" , Jan Kara , "linux-nvdimm@lists.01.org" , Dave Chinner , "linux-kernel@vger.kernel.org" , linux-xfs@vger.kernel.org, Jeff Moyer , Alexander Viro , Andy Lutomirski , linux-fsdevel , Ross Zwisler , Linux API Subject: Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap Message-ID: <20170811104429.GA13736@lst.de> References: <150181368442.32119.13336247800141074356.stgit@dwillia2-desk3.amr.corp.intel.com> <20170805095013.GC14930@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: On Sun, Aug 06, 2017 at 11:51:50AM -0700, Dan Williams wrote: > Of course it's a useful API. An application already needs to worry > about the block map, that's why we have fallocate, msync, fiemap > and... Fallocate and msync do not expose the block map in any way. Proof: they work just fine over say nfs. fiemap does indeed expose the block map, which is the whole point. But it's a debug tool that we don't event have a man page for. And it's not usable for anything else, if only for the fact that it doesn't tell you what device your returned extents are relative to. > > We've been through this a few times but let me repeat it: The only > > sensible API gurantee is one that is observable and usable. > > I'm missing how block-map immutable files violate this observable and > usable constraint? What is the observable behavior of an extent map change? How can you describe your immutable extent map behavior so that when I violate them by e.g. moving one extent to a different place on disk you can observe that in userspace? > This immutable approach should also go in, it solves the same problem > without the the latency drawback, How is your latency going to be any different from MAP_SYNC on a fully allocated and pre-zeroed file? > Beyond flush from userspace it also > can be used to solve the swapfile problems you highlighted Which swapfile problem? > and it > allows safe ongoing dma to a filesystem-dax mapping beyond what we can > already do with direct-I/O. Please explain how this interface allows for any sort of safe userspace DMA.