The NOVA filesystem [LWN.net]

The NOVA filesystem

Posted Aug 6, 2017 19:20 UTC (Sun) by Tara_Li (guest, #26706)
In reply to: The NOVA filesystem by corbet
Parent article: The NOVA filesystem

But I thought the point of persistent memory is that it is *just* memory - when you shut the machine down, the CPU quits incrementing the instruction pointer and the system shuts down. When you hit the power button, the instruction pointer picks right back up and the machine keeps running. The memory is managed by the standard memory manager, I would expect - programs know where their memory is supposed to be. The image I'm getting here is that "persistent memory" is nothing but marketing speak - it's actually just a SSD.

The point

Posted Aug 6, 2017 19:42 UTC (Sun) by corbet (editor, #1) [Link] (1 responses)

Many years ago, I worked with a Data General Nova machine that had core memory. It worked that way: turn it off at the end of the day, and it would pick up where it left off in the morning. Most of the time.

Persistent memory is not core memory, though, and it's not a replacement for DRAM, at least not now; it has rather different performance characteristics. So systems will have both types of memory for the foreseeable future. It differs rather significantly from an SSD, though, in that it is byte-addressable by the CPU. That changes a lot of the calculations and is why filesystems like NOVA may make sense.

The point

Posted Aug 9, 2017 13:24 UTC (Wed) by JFlorian (guest, #49650) [Link]

You and I share a common history there. A DG Nova was my first experience with a larger system. I'm always amazed at how far technology has advanced, but this reminder was rather jarring (in a good way).

The NOVA filesystem

Posted Aug 7, 2017 6:24 UTC (Mon) by jem (subscriber, #24231) [Link] (1 responses)

> When you hit the power button, the instruction pointer picks right back up and the machine keeps running.

For that you need not only persistent memory, but also a persistent CPU.

> The image I'm getting here is that "persistent memory" is nothing but marketing speak - it's actually just a SSD.

The big conceptual difference is that the CPU can address the memory directly. The CPU is able to store and load data, and execute code just like with ordinary RAM. That's not possible with today's SSDs.

The NOVA filesystem

Posted Aug 13, 2017 21:30 UTC (Sun) by giraffedata (guest, #1954) [Link]

When you hit the power button, the instruction pointer picks right back up and the machine keeps running.
For that you need not only persistent memory, but also a persistent CPU.

You need persistent a lot more than that. Main memory is only one of myriad holders of state in a computer. Look at how hard suspend/resume is. You can't just store the contents of main memory, power down, then restore that memory upon power up and keep going. Every device in the computer has some volatile memory in it (disk controllers, for example). And since you can't keep the time of day persistent, there is some difficulty there too.

The image I'm getting here is that "persistent memory" is nothing but marketing speak - it's actually just a SSD.
The big conceptual difference is that the CPU can address the memory directly.

This misses Tara_Li's point. This difference affects only what kernel code you write to use it. The user still sees persistent storage that works at solid state speeds, that you could use to store data, which is exactly what SSDs are all about.

But Jon points out one difference between persistent memory and SSD that could actually make a difference in its application: persistent memory is byte-addressable.

The NOVA filesystem

Posted Aug 16, 2017 13:56 UTC (Wed) by anton (subscriber, #25547) [Link]

Software has problems like memory leaks and bugs that make process persistence less practical than it may appear at first.

E.g., some earlier version of Microsoft Word exhibited many of the disadvantages of trying to work with process persistence only: When the user saved the document, it produced more or less a dump of its memory, and when loading the document, the memory dump was restored. The document contained a lot of stuff that had been deleted by the user (which led to various interesting findings), and if the memory was corrupted in some way (that would lead to a crash on certain operations), that corruption would end up in the saved document, persisting the crash across the save. Letting a new version of Word load an old document was probably a major programming feat, and the other way was not possible at all.

Saving data in a well-defined format instead of just keeping it in persistent process memory or saving it as a memory dump is more work at first, but it pays off.

We have had persistent OSs like EROS for decades (they saved the changed pages to disk every 30s or so, so you would lose up to that amount of work on a crash, much like with file systems), but they did not catch on, nor did mainstream OSs acquire process persistence features (well, there's hibernation, but the OS is still not designed to let processes live forever). Maybe now, with containers.

So when we have a persistent variant of RAM, we still need to save data from processes, so we still need a file system. The choice of having a log-structured base for such a file system surprised me, though.