On Mon, 12 Sep 2016 08:01:48 -0700 Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > 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. Not really. A few reasonable changes can be made to improve things. Until just now you thought it was fundamentally impossible to make a reasonable implementation due to Dave's "constraints". > > > 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. Nothing that says you have to use them fully mapped always and not use other APIs on them. > 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. That's circular logic. First you said that should not be done because of your imagined constraints. In fact, it's not unreasonable to describe some additional semantics of the storage that is unavailable with traditional filesystems. That said, a noop system call is on the order of 100 cycles nowadays, so rushing to implement these APIs without seeing good numbers and actual users ready to go seems premature. *This* is the real reason not to implement new APIs yet. > 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. Those constraints don't exist either. I've written a filesystem that avoids them. It isn't rocket science. -- 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>