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.

quoted

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.