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