Preparing for nonvolatile RAM

Posted May 24, 2012 20:48 UTC (Thu) by daglwn (guest, #65432)
Parent article: Preparing for nonvolatile RAM

I think Vyacheslav Dubeyko is on the right track. If NVRAM is as fast as DRAM and cheaper, there will be really no reason to have DRAM at all. At that point, you don't need filesystems anymore.

In fact we don't really need filesystems today. We could simply use the paging system to write out the contents of memory to persistent storage on a shutdown and load them back up on a restart, not unlike suspend/resume. Pointers become the names of objects.

Preparing for nonvolatile RAM

Posted May 24, 2012 23:26 UTC (Thu) by viro (subscriber, #7872) [Link] (16 responses)

... and with pointers being used instead of pathnames, we are suddenly in a situation when what used to be text (you know, C source, makefiles, etc.) contains pointers. Oh, the rapture... Pardon me, but I'm unimpressed.

Preparing for nonvolatile RAM

Posted May 24, 2012 23:40 UTC (Thu) by daglwn (guest, #65432) [Link] (15 responses)

Oh come on. One can certainly have mappings between user-readable handles and objects.

The point is that we have an entire OS subsystem that probably isn't needed at all for a lot of use cases. Who wouldn't want to get rid of that complexity.

Preparing for nonvolatile RAM

Posted May 25, 2012 3:48 UTC (Fri) by viro (subscriber, #7872) [Link] (14 responses)

... and that's what filesystem _is_. No more, no less. It's a mechanism mapping pathnames to objects. Look at Multics, for fsck sake - everything is mmappable segment (and the entire address space of process consists of those; 36bit address split into 18bit segment and 18bit offset, with per-segment page tables and segments sharable between the processes), regular files are segments (with on-disk bits used as persistent storage), directories are *also* segments containing essentially pairs (name, segment reference). Said references may refer to regular files or to directories, giving you hierarchical namespace in usual way. All file IO done via mmap + direct memory access.

What do you think 'ls' stands for? That's right, "list segments". In a directory segment, that is. As for the supposed complexity... Take a look at the amount of code in fs/ramfs someday. Especially if you leave no-MMU side of things alone...

Preparing for nonvolatile RAM

Posted May 29, 2012 20:40 UTC (Tue) by daglwn (guest, #65432) [Link] (13 responses)

Come on Al, you're being deliberately dense. All that filesystem code ALSO optimizes access for rotating storage, does buffering, etc. Why the heck do we need a file cache at all if we don't have a slow disk?

There is a lot of complex code that could be dumped if everything lived in a random-access memory. Device drivers alone would be a huge savings.

Preparing for nonvolatile RAM

Posted May 29, 2012 21:33 UTC (Tue) by paulj (subscriber, #341) [Link] (5 responses)

I'm curious, where in the VFS is the complex code for optimising rotating storage, buffering, etc? Or where/how does the API for the VFS require fs implementations to do that kind of thing?

Preparing for nonvolatile RAM

Posted May 30, 2012 1:36 UTC (Wed) by daglwn (guest, #65432) [Link] (4 responses)

If you don't have a filesystem model you don't have a VFS and you don't have filesystems. I'm really quite surprised at the pushback here. It's an idea. Don't get bent out of shape.

Preparing for nonvolatile RAM

Posted May 30, 2012 4:43 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

There are a lot of people who have advocated eliminating filesystems.

However, they have always run into the stumbling block that it's just impractical to deal with all hunks of data in a flat namespace. Directories are EVIL, but nobody has make anything else work even one tenth as well

Also, just keeping everything in ram falls apart as soon as you want someone else to access it (or you loose the device, or the device gets destroyed, or ...)

Many of the people pushing back have been though this "eliminate filesystems" experiment before and have the scars to show for it. Listen and learn (then go try and build something to prove them wrong :-)

Preparing for nonvolatile RAM

Posted May 31, 2012 19:35 UTC (Thu) by timka.org (guest, #53366) [Link]

Dmitry Zavalishin, the author of Phantom OS (which "eliminates filesystems"), was asked the question about removable storage when he was giving a talk about the OS at HighLoad++ in 2009.

His idea is to start a separate Phantom VM for a removable media which then can be seen as another "host" accessible via "network". AFAIU, this means Phantom's native IPC is substituted by some protocol. Smells somewhat like Plan 9 to me.

Preparing for nonvolatile RAM

Posted May 30, 2012 4:52 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

But you said you would still have a layer to provide user-friendly namespace, and a translation between that and the actual memory handles. You seem to think the current VFS is far more than that, that the current VFS does things like block-IO buffering and has other arcane IO related knowledge. So where does the VFS have anything like that?

Preparing for nonvolatile RAM

Posted May 30, 2012 14:54 UTC (Wed) by daglwn (guest, #65432) [Link]

The VFS doesn't. The fs layers and drivers do.

I think the discussion is pretty pointless now...

Preparing for nonvolatile RAM

Posted May 30, 2012 0:11 UTC (Wed) by Trelane (subscriber, #56877) [Link] (1 responses)

> Why the heck do we need a file cache at all if we don't have a slow disk?

Because not all memory is the same, let alone the pipe over which we get it.

How would you use a hypothetical storage medium that had 1EB of storage but you could only access it at 128kbps?

Preparing for nonvolatile RAM

Posted May 30, 2012 1:37 UTC (Wed) by daglwn (guest, #65432) [Link]

Probably the same way we handle networks today.

The filesystem is the abstraction and that abstraction has certain costs. Changing the abstraction doesn't imply we immediately forget everything we know.

Preparing for nonvolatile RAM

Posted May 30, 2012 6:53 UTC (Wed) by viro (subscriber, #7872) [Link] (4 responses)

RTFS. I've even told you which source to read.

One more time, slowly:

* fs/ramfs/inode.c does *not* optimise for rotating storage, what with having nothing whatsoever to do with any storage.

* it does *not* optimise for disc buffering, what with having no backing storage, disc or otherwise

* file cache (page cache, really) is just a mechanism for finding a page by offset in file. In case of object living entirely in RAM, that's exactly what you need to work with that object. Unless you want your objects to be contiguous in RAM, that is - great idea, that, for e.g. 800Kb text file. Or a 22Mb PDF document.

* Device drivers have nothing whatsoever to do with aforementioned ramfs.

* You have demonstrated just what is wrong with "visionaries". You keep making profound sounds without stopping to check whether they have anything to do with reality. Other than that of your bowel movements, that is.

As for being deliberately dense... I wouldn't have dared - any attempt to fake being dense would be simply pathetic next to the geniune article of that magnitude.

Preparing for nonvolatile RAM

Posted May 30, 2012 14:55 UTC (Wed) by daglwn (guest, #65432) [Link] (3 responses)

Thanks, Al. Real classy. It truly makes me want to learn more.

Preparing for nonvolatile RAM

Posted May 30, 2012 21:25 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Well, you should.

Don't know about you, but after Al Viro's post I went and checked VFS source code - and he's entirely correct.

Preparing for nonvolatile RAM

Posted May 30, 2012 21:59 UTC (Wed) by daglwn (guest, #65432) [Link] (1 responses)

I'm sure he is correct. But he doesn't have to be an ass about it. He started right off with unwarranted sarcasm, graduated to foul language and it went downhill from there, leading to personal attacks.

I never claimed to be a "visionary." I'm far, far from that. The idea isn't even original, people have talked about it for years. It just strikes me that it makes a lot of sense given system architecture trends. Outright dismissal accompanied by foul language, holier-than-thou attitudes and outright insults says much more about Al than it does me.

Al definitely lost a notch or too on my respect ladder and that's a pity because I've generally enjoyed reading his posts/articles.

Preparing for nonvolatile RAM

Posted May 31, 2012 1:29 UTC (Thu) by bronson (subscriber, #4806) [Link]

I suppose the sarcasm is warranted if it's an idea that's proposed by many well-intentioned but ill-informed people. It attempts to keep the conversation short or, failing that, provide car-crash style entertainment. "Bring facts or suffer ridicule."

I'm no linguist but anybody who disagrees is a dweeb. :)

Preparing for nonvolatile RAM

Posted May 25, 2012 1:18 UTC (Fri) by iabervon (subscriber, #722) [Link] (7 responses)

You'll notice that we have at least three filesystems (tmpfs, procfs, and sysfs) which don't use anything other than RAM. You'll also notice that programs make extensive use of filesystems for the well-specified inter-process semantics around the common case where the computer doesn't lose power and RAM keeps working.

Oh, and we use filesystems for disks, which NVM doesn't replace, not for DRAM, which NVM does replace. It would make more sense to say that now we can now have *only* filesystems, not anonymous memory. But that's also dumb.

Preparing for nonvolatile RAM

Posted May 25, 2012 1:53 UTC (Fri) by neilbrown (subscriber, #359) [Link]

Thank you for saying that, it saved me the trouble. (aka "+1").

Preparing for nonvolatile RAM

Posted May 25, 2012 3:03 UTC (Fri) by daglwn (guest, #65432) [Link] (5 responses)

And this is all because we think the filesystem abstraction is the only way to go. NVRAM certainly could replace disks on some devices and really, what's the difference between storing data on disk in a filesystem and storing on disk in the form of pages?

There are many other, better ways to do IPC.

I don't think a filesystem-less Linux would work that well - the concept is too ingrained into the kernel. But starting from scratch? I would seriously consider not providing a filesystem at all.

Preparing for nonvolatile RAM

Posted May 25, 2012 5:10 UTC (Fri) by mrons (subscriber, #1751) [Link] (1 responses)

There have been operating systems that have removed the filesystem abstraction. I recall reading about the Monads system in the 80's:

http://www.jlkeedy.net/research-highlights.html

Don't know how far they got with an actual implementation though.

Preparing for nonvolatile RAM

Posted May 31, 2012 19:56 UTC (Thu) by timka.org (guest, #53366) [Link]

There's also Phantom OS. Never tried it myself but it's still active and looks interesting.

Preparing for nonvolatile RAM

Posted May 25, 2012 8:52 UTC (Fri) by dgm (subscriber, #49227) [Link] (2 responses)

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.

Preparing for nonvolatile RAM

Posted May 29, 2012 20:45 UTC (Tue) by daglwn (guest, #65432) [Link] (1 responses)

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.