On Sat, Aug 5, 2017 at 2:50 AM, Christoph Hellwig <hch@xxxxxx> wrote: > On Thu, Aug 03, 2017 at 07:38:11PM -0700, Dan Williams wrote: >> [ adding linux-api to the cover letter for notification, will send the >> full set to linux-api for v3 ] > > Just don't send this crap ever again. All the so called use cases in the > earlier thread were incorrect and highly dangerous. I usually end up coming around to your position on these types of debates because you almost always put forward unassailable technical arguments. So far, you have not in this case. > Promising that the block map is stable is not a useful userspace API, > as it the block map is a complete internal implementation detail. 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... > 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? > so Jan's synchronous page fault flag in one form or another makes > perfect sense as it is a clear receipe for the user: you don't > have to call msync to persist your mmap writes. This API is not, > it guarantees that the block map does not change, but the application > has absolutely no point of even knowing about the block map. Jan's approach is great, it should go in, it solves a long standing problem with dax with the only drawback being potentially unpredictable latency spikes. This immutable approach should also go in, it solves the same problem without the the latency drawback, but yes, with the administrative overhead of CAP_LINUX_IMMUTABLE. Beyond flush from userspace it also can be used to solve the swapfile problems you highlighted and it allows safe ongoing dma to a filesystem-dax mapping beyond what we can already do with direct-I/O. There is demand for these capabilities that cannot be satisfied by just hand waving them away as invalid. The magnitude of opposition to this approach is out of step with the actual risk. -- 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
