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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
