Messages in this thread |  | | Date | Fri, 11 Aug 2017 12:44:29 +0200 | From | Christoph Hellwig <> | Subject | Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap |
| |
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.
|  |