Preparing for nonvolatile RAM

By Jonathan Corbet
May 23, 2012

Once upon a time, your editor had a job that involved working with a Data General Nova system. The Nova had an interesting characteristic: since it contained true core memory, the contents of that memory would persist across a reboot—or a power-down. So the end-of-day shutdown procedure was a simple matter of turning the machine off; when it was turned on the next morning, it would simply continue where it was before. There were no complaints about system boot time with that machine. The replacement of core memory with silicon-based RAM brought a lot of nice advantages, but the nonvolatile nature was lost on the way. But it appears that nonvolatile memory may be about to make a comeback, bringing some interesting development problems with it.

Matthew Wilcox raised the issue, noting that nonvolatile memory (NVM) is coming, that it promises bandwidth and latency numbers similar to those offered by dynamic RAM, and that, being cheaper than DRAM, it is likely to be offered in larger sizes than DRAM is. He later disclaimed any resemblance between this description and any future products to be offered by his employer; it is, he says, simply where the industry is going. Given that, it would be a good idea for the kernel community to be ready for this technology when it arrives.

One part of being ready is figuring out how to deal with nonvolatile memory within the kernel. The suggested approach was to use a filesystem:

We think the appropriate way to present directly addressable NVM to in-kernel users is through a filesystem. Different technologies may want to use different filesystems, or maybe some forms of directly addressable NVM will want to use the same filesystem as each other.

A filesystem approach would allow the association of names with regions of NVM space; an API was then proposed to allow the kernel to perform tasks like mapping regions of NVM into the kernel's address space.

One question that came up quickly was: won't the use of the filesystem model slow things down? There is a lot of overhead in the block layer, which was not designed to deal with "storage" that operates at full memory bandwidth. Matthew was never thinking of bringing in the full block layer, though; instead, he said: "I'm hoping that filesystem developers will indicate enthusiasm for moving to new APIs". Such enthusiasm was in short supply in this discussion; that is probably more indicative of a lack of thought about the problem than any sort of active opposition (which was also in short supply).

James Bottomley, though, questioned the filesystem idea, suggesting that NVM should be treated like memory. He said that the way to access NVM might be through the kernel's normal memory APIs, with nonvolatility just being another attribute of interest. One could imagine calling kmalloc() with a new GFP_NONVOLATILE flag, for example. The only problem with this approach is that it is not enough to request an arbitrary nonvolatile region; callers will usually want a specific NVM region that, presumably, contains data from a previous use. So the memory API would have to be extended with some sort of namespace giving reliable access to persistent data. To many, that namespace looks like a filesystem; James suggested using 32-bit keys like the SYSV shared memory mechanism does, but admirers of SYSV IPC tend to be scarce indeed on linux-kernel.

So, while there are a lot of details to be worked out, some sort of name-based kernel API seems certain to come about. Then there will be a mechanism, either through the memory-related or filesystem-related system calls, to make NVM available to user space. But that leads to another, perhaps harder question: what, then, do we do with all that fast, nonvolatile memory?

Some of it, certainly, could be used for caching; technologies like bcache could make good use of it. The page cache could go there; Matthew suggested that the inode cache might be another possibility. Both could speed booting considerably, though it would be necessary to somehow validate the cache contents against filesystems that could have changed while the system was down. Boaz Harrosh suggested that filesystems could store their journals in that space, speeding journal access and reducing journal I/O load on the underlying storage devices. He also mentioned checkpointing the system to NVM, allowing for quick recovery should the system go down unexpectedly. Vyacheslav Dubeyko had some wilder ideas about how NVM could eliminate system bootstrap entirely and make the concept of filesystems obsolete; instead, everything would just live in a persistent object environment.

Clearly, many of these ideas are going to take some time to come to fruition. Nonvolatile memory changes things in fundamental ways; Linux may have to scramble to keep up, but, then, that is a high-quality problem to have. It will be most interesting to watch how this plays out over the coming years.

Index entries for this article
Kernel	Memory management/Nonvolatile memory

Preparing for nonvolatile RAM

Posted May 24, 2012 2:03 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

Yes, I remember working with core memory. It was very convenient.

Perhaps mmap is the right abstraction: if a file is mmap'ed read-write it is randomly addressable and persistent. Another alternative, if the NVRAM is as fast as any other RAM, is to ignore the nonvolatile characteristic and use it as ordinary memory. Or it could be a mixture of both: users can create files in it and what's left is available as memory.

Preparing for nonvolatile RAM

Posted May 24, 2012 3:12 UTC (Thu) by pj (subscriber, #4506) [Link] (1 responses)

I've been thinking for awhile that RAM, NVM, flash, and disks are all part of a continuum of storage with various latencies and qualities (persistent, rewritable, clearable) and it would be interesting to try and unite the interfaces to all of them, and perhaps write different 'services' for them. A persistent-block service would look like a block device. A non-persistent page-storage service would look like current memory management. This would, I think, make some of the blurry-edged cases clearer: page files fall out quite easily, and caching at all levels could likely be united - so the page cache is just like the block cache.

I dunno, just an idea I had awhile back.

Preparing for nonvolatile RAM

Posted May 24, 2012 17:41 UTC (Thu) by cesarb (subscriber, #6266) [Link]

This might interest you: https://en.wikipedia.org/wiki/Single-level_store

I guess I am a little slow here

Posted May 24, 2012 13:24 UTC (Thu) by felixfix (subscriber, #242) [Link] (9 responses)

I too remember core memory.

I do not understand the problem as posed here, nor the responses. Why not just treat it exactly like a regular suspend and wakeup? The sole difference is that some peripherals may have lost power, including the usually-non-removable disk drives.

What is the point of trying to make it look like a disk? It reminds of those fun projects to run Linux on a 6502 emulator running under Windows running under Wine on Linux. Fun, interesting ... but ultimately silly.

I guess I am a little slow here

Posted May 24, 2012 18:44 UTC (Thu) by iabervon (subscriber, #722) [Link] (8 responses)

It's a bit different from usual suspend/resume if you have both DRAM and NVM, and you could have some memory areas lose power and others persist. You're also likely to have some interesting effects with the BIOS going through its boot instead of its resume, and leaving devices configured in an unexpected way.

I think the point of making it look like a disk is the same as the point of having tmpfs: it's nice to have filesystems (with their actual benefit of namespaces, naming, and authorization properties) with full memory bandwidth.

It's also possible that it would be beneficial to be able to keep data in NVM usefully while switching to a new kernel, which requires some sort of in-storage data structures which are stable across kernel versions.

I guess I am a little slow here

Posted May 24, 2012 19:16 UTC (Thu) by dlang (guest, #313) [Link] (5 responses)

if NVM is as fast as DRAM and higher desnity, why would people still have DRAM in their system?

Uses for NVM

Posted May 24, 2012 23:42 UTC (Thu) by giraffedata (guest, #1954) [Link] (3 responses)

if NVM is as fast as DRAM and higher density, why would people still have DRAM in their system?

Don't forget cheaper.

I think the real question may be: after you replace all your DRAM with NVM and do the obvious suspend/resume exploitation, what more can you do with all the additional NVM you have in excess of what used to be DRAM. The article's reference to "available in larger sizes" alludes to this.

A bigger file cache in the kernel was mentioned. This would address the problem some systems have today that their file cache size is limited by how long it takes to prime it after each boot.

The filesystem idea seems to allude to using it for stuff we used to keep on SSDs, but were limited by the cost of dragging it over a SATA wire into a CPU register (stopping off at DRAM along the way).

Uses for NVM

Posted May 24, 2012 23:57 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

when they say "available in larger sizes", what sort of sizes are they talking about?

if they are talking about sized 2x -4x larger than current DRAM devices, the answer is simple, you will use all that you have as normal RAM and not have 'extra' to find a use for.

If they are talking 20x+ larger, then it may start replacing flash in systems. but unless they are talking significantly larger than that, they won't start replacing spinning rust

Uses for NVM

Posted Jun 2, 2012 9:45 UTC (Sat) by Duncan (guest, #6647) [Link] (1 responses)

This realistic, cautionary note seems IMO to be the best comment so far (in time), both above and below yours. Let's look at what we have:

Using pricewatch.com as a guide on going street-price, current near-best prices (note that for most gig quantities, prices are higher, and of course spinning rust comes in far larger gig quantities... I simply quickly scanned and picked what appeared to be the best gigs per $ in each category) :

DRAM ~ $4/gig ($32ish, 8 gig)

SSDs ~ $1/gig ($230, 240 gig)

Flash ~ 50 cents a gig ($16, 32 gig USB stick)

Spinning rust 3.5 inch ~ 5 cents a gig ($145, 3000 gig)
Spinning rust 2.5 inch ~ 9 cents a gig ($$60, 640 gig)

Now it's worth considering just what this NVRAM is being compared against. It's being compared against $4+/gig DRAM, similar latency, higher density, lower cost, except that it happens to be non-volatile.

It's *NOT* being compared against the next step down in both price and latency, SSDs, except lower latency, higher bandwidth, tho its non-volatile nature might make that a more logical direct comparison.

That certainly says a great deal about at least the intended price point. They'd rather be compared against $4/gig DRAM than against $1/gig SSDs.

OK, that sets some pretty close bounds on the practical price-point, well under an order of magnitude. We're looking at, probably, $2-3/gig at today's capacity/price points, tho of course all three technologies (SSD, NVRAM, DRAM) can be predicted to be somewhat below that by the time it comes out in reasonable quantities and target sub-dram prices (the time frame wasn't mentioned, but maybe a couple years?)

You've made a very practical point that at the target sub-dram price-point (tho you said size/capacity, but price per capacity is I believe the controlling factor, or we'd all be using battery-backed DRAM storage for our tibibytes of videos!), perhaps half that of dram, in practice we're simply talking a cheaper dram replacement that has one very different property than current dram -- non-volatility.

That means it's *NOT* going to be the end of the world as we know it. We're simply looking at, for the most part, a cheaper dram with one rather interesting quality compared to current dram. We're NOT, at least near term, going to be replacing spinning rust, for sure.

While it's likely to replace current tech SSDs at the high end, that's likely to simply push them down-market a bit, much as SSDs forced spinning rust down-market quite a bit. Current tech SSDs will in turn drop back toward on par with flash, where it seems they settled for quite awhile, altho they're double flash's price ATM. That will hopefully in turn push flash prices down... so were this NVRAM available at the target price-points today, we might see something like this instead of the above.

DRAM, $3/gig

NVRAM, $2/gig,

SSD, 80 cents/gig

Flash, 40 cents/gig

Spinning rust, 4 cents/gig 3.5, 8 cents/gig 2.5

Or for a time NVRAM might floor the dram market, to say $2/gig (relative), with NVRAM at $1.50/gig, then actually increase the price of dram as it gets eclipsed and drops from competitive so that prices for dram don't fall in line with the rest of the market, thus going up relative to it, such that people might end up with half-gig dram machines again, the rest nvram, and dram costing (relative, the whole market would of course be cheaper by then) say $6-8/gig low end as a result. (The dynamic would thus be much like that for eclipsed memory technologies like DDR-1 and PC100/133, today. You can compare their prices per gig on pricewatch, or your favorite alternative, if you like. I just took a WAG above, but just checked and $6-8/gig for DDR is pretty close, actually, PC100/133 about double that! Prices for eclipsed tech do drop, but not by nearly as much, relative to current tech.)

The big point of course being that all this talk about killing filesystems or even SSDs and spinning rust... is VERY premature, to say the least! Otherwise, the comparison would as I said, be to SSDs, but lower latency and higher bandwidth, not to dram, but non-volatile.

Of course predicting ten years out is a tough business. By then, this could well either look like a flash in the pan or could have taken over the whole market. But more likely, it'll be simply incremental, spinning rust will still be around for our then approaching petabyte needs and nvram may or may not have replaced dram and/or ssds but may, if it survives, be used like one or the other, or both, and the world will go on much like it does today, but different, just as today is much like 2002, but different.

Uses for NVM

Posted Jun 2, 2012 20:43 UTC (Sat) by dlang (guest, #313) [Link]

if NVRAM is bigger, cheaper, and faster than DRAM (or worst case, equivalent in any or all of these categories), why would anyone still use DRAM?

This is similar to the way that flash has essentially eliminated both ROM and EEPROM from the market.

I guess I am a little slow here

Posted May 25, 2012 0:41 UTC (Fri) by iabervon (subscriber, #722) [Link]

He actually said "similar latency and throughput"; the difference could be enough that we'll see systems with some of each.

I guess I am a little slow here

Posted May 24, 2012 23:49 UTC (Thu) by felixfix (subscriber, #242) [Link] (1 responses)

Why would the BIOS not know it has NVRAM?

Some things simply are not upgradeable. If you have an old computer with DRAM, you almost certainly won't be able to replace the DRAM with NVRAM.

And if the NVRAM computer comes with a BIOS that thinks it needs to set up refresh cycles and such, it is much too broken to buy, and anyone who does gets what they deserve.

I guess I am a little slow here

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

When the power comes up and the machine has NVM, the BIOS doesn't necessarily know whether the NVM actually contains anything useful (or salvageable-- the processors may have lost power without suspending cleanly, which the OS may or may not be clever enough to sort out). And you might be trying to boot an old OS or be switching OSes entirely. So I expect that what will happen is that the BIOS will pass control to the bootloader on powerup (having clobbered the first 640k of RAM, most likely), and the bootloader has to recognize that we have a kernel in NVM already and return to its recovery point instead of loading a kernel off of the boot medium.

Of course, you could also just say, "unexpected power failures are still fatal; the only benefit of NVM is that you can remove all power while cleanup suspended." I'd expect that to be the behavior if the OS doesn't know about NVM, but I think being able to recover from unexpected power failures is more interesting.

Paging AS/400 veterans

Posted May 24, 2012 18:24 UTC (Thu) by ncm (guest, #165) [Link]

We should be able to learn something from the experience of those who have worked with/on IBM's AS/400 and its OS, nowadays called "IBM i". As I recall, in its original release it didn't have a file system. Instead, every call to malloc(), over the life of the machine, would return a different (128-bit) numeric value. Anything put there would be accessible indefinitely, across reboots and substitution of underlying hardware. Replace the 32-bit CPU with a quad 64-bit, and your programs don't notice. As far as programs running on it were concerned, it never shut down; restore power and whatever was running picks up where it left off.

In place of a file system, programs exchange pointer values. You can construct a name mapping if you want, or several (and they did), but the OS doesn't insist on it. In effect, every file is memory-mapped, and its inode number is also a pointer to it; alternatively, every allocated memory block is also a file, and its name is also a pointer to it.

AS/400 sneers at your uptime statistics.

Data General core machines

Posted May 24, 2012 19:11 UTC (Thu) by maney (subscriber, #12630) [Link]

I worked on mostly Eclipse machines one summer years back. There was one annoying problem with that scheme: the machine's main power switch had three positions, off, on, and locked IIRC, the last being the save to and restore from core. The problem was that this meant that both AC line and a logic signal that ran more or less directly into the middle of one of the two 15" square boards that implemented the CPU were on contacts only a fraction of an inch apart. And every now and then one of those switches would fail in the worst possible way...

It was interesting trying to fix that CPU board set - microcoded diagnostics kept leading us to change more chips (this was gate level TTL, the microcode ROM & RAM and the ALU slices were about the most complex chips), and it always seemed we were making progress. Then they wondered why this one job was taking so long, which is when they told us about this interesting failure mode, and the board set was sent to the scrap heap.

Preparing for nonvolatile RAM

Posted May 24, 2012 20:48 UTC (Thu) by daglwn (guest, #65432) [Link] (25 responses)

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.

Preparing for nonvolatile RAM

Posted May 24, 2012 21:54 UTC (Thu) by tbird20d (subscriber, #1901) [Link]

No one has brought up PRAMFS, which seems like a natural fit for this.

Preparing for nonvolatile RAM

Posted May 25, 2012 10:51 UTC (Fri) by drag (guest, #31333) [Link]

I vote for using something like tmpfs, but with the ability to execute in place. Like what is used in some embedded systems.

http://en.wikipedia.org/wiki/Execute_in_place

Fragmentation would be a serious problem so it would be necessary to revist and improve the anti-defrag memory patches and such that I've seen discussed here in the past.

Like:
http://lwn.net/Articles/211505/

As far as booting and dealing with BIOS...

Have the bootloader bootstrap the system just enough to just start executing whatever is at 0x0 on the NVRAM. Then leave it up the kernel to notice that the system just was booted and undo whatever brain dead state the UEFI or BIOS or whatever just put the system into.