It would not work. There are two use cases that the pointer/page combination doesn't cover, namely: removable storage and named data. Both are very important, so a system that doesn't support them will not be very useful.
And as Viro said above, the moment you add a name->page mapping... voilĂ ! the filesystem is back.
Posted May 29, 2012 20:45 UTC (Tue) by daglwn (subscriber, #65432)
[Link]
I guess I'm not following what's so special about "named data." Ultimately it's a mapping from a user-readable handle to a machine-readable handle. And no, such a mapping does not have to look like a filesystem at all. We don't necessarily even want a concept of directories as such, for example.
I'll grant that removable media presents a challenge. But with The Cloud(TM) these days, do we even need it? I'm talking about certain common use cases. Certainly we need it for lots of things but I don't think everyone in the world needs it.
Even so, I wonder if page migration could be adapted to support removable storage. Page out on one system, page back in on another.
Just thinking blue sky here, I'm not an expert on any of this.
Preparing for nonvolatile RAM
Posted Jun 1, 2012 1:07 UTC (Fri) by kevinm (guest, #69913)
[Link]
What people are trying unsuccessfully to point out is that *all* the "filesystem abstraction" is is a mapping from a hierarchical name and offset into a memory address. That's all it is.
About that only thing you can change that about that and still have a mapping from names to memory is to change what the names look like. Maybe you don't want them to be hierarchical - maybe you want them to be flat, or multidimensional instead of single-dimensional. But there doesn't seem to be a good reason why changing how the names look is in any way related to NVM.