On Mon, Sep 12, 2016 at 06:05:07PM +1000, Nicholas Piggin wrote: > It's not fundamentally broken, it just doesn't fit well existing > filesystems. Or the existing file system architecture for that matter. Which makes it a fundamentally broken model. > Dave's post of requirements is also wrong. A filesystem does not have > to guarantee all that, it only has to guarantee that is the case for > a given block after it has a mapping and page fault returns, other > operations can be supported by invalidating mappings, etc. Which doesn't really matter if your use case is manipulating fully mapped files. But back to the point: if you want to use a full blown Linux or Unix filesystem you will always have to fsync (or variants of it like msync), period. If you want a volume manager on stereoids that hands out large chunks of storage memory that can't ever be moved, truncated, shared, allocated on demand, etc - implement it in your library on top of a device file. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>