The NOVA filesystem [LWN.net]

The NOVA filesystem

Posted Aug 5, 2017 15:09 UTC (Sat) by Tara_Li (guest, #26706)
Parent article: The NOVA filesystem

What I don't quite get is ... it's memory. Why not just treat it as memory? Shift the processor into 64-bit address space mode and just call it allllll memory.

to post comments

The NOVA filesystem

Posted Aug 5, 2017 15:55 UTC (Sat) by corbet (editor, #1) [Link] (7 responses)

It's not just memory, it's persistent memory. But persistence is only useful if you can find stuff later. As mentioned in the article, that means you need some sort of directory structure.

The NOVA filesystem

Posted Aug 6, 2017 19:20 UTC (Sun) by Tara_Li (guest, #26706) [Link] (6 responses)

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 NOVA filesystem

Posted Aug 6, 2017 19:38 UTC (Sun) by josh (subscriber, #17465) [Link]

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

That's an eventual goal, but for compatibility with existing software, that doesn't happen yet. And the rest of the hardware on the system doesn't work without power, either, so it's more like suspend-to-RAM but with zero power usage.

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.

The NOVA filesystem

Posted Aug 5, 2017 18:05 UTC (Sat) by Paf (subscriber, #91811) [Link] (4 responses)

In addition to what Corbet noted, most of the proposed tech sits between flash and true RAM in terms of performance. 10x-1000x slower than RAM, depending on tech and what you're measuring (and whose claims of future performance you believe). One could end up quite sad from expecting truly RAM like performance from some persistent memory solutions.

(The above leaves out battery backed DIMMs, I suppose. But they don't seem like a tech with broad applicability.)

The NOVA filesystem

Posted Aug 6, 2017 3:03 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

The current tech is basically a mock-up of future persistent RAM. It's expected to be within the usual DRAM performance range, if not that durable. It'll certainly be faster than flash.

The NOVA filesystem

Posted Aug 6, 2017 17:54 UTC (Sun) by Paf (subscriber, #91811) [Link] (2 responses)

Really? Is it? Intel's marketing of 3D xpoint (available now) sort of suggests it will be RAM level, but the actual numbers are well off. They're faster than flash, but they live between flash and RAM.

They're claiming they'll be ~0.5 microsecond latency, but current 3D xpoint stuff is more like 5 microseconds. Flash is more like 100 microseconds, DRAM is 5-30 nanoseconds. So another 100x faster than 3D xpoint, 1000x if you use the latencies of what you can buy today.

Those numbers are from memory mostly, but I'm pretty sure they're broadly correct. Maybe there's other tech or I've got the #s off a bit...?

So it creates another (fascinating) stopping point in the storage/memory/cache hierarchy.

The NOVA filesystem

Posted Aug 7, 2017 2:23 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

You can not buy 3D xpoint on the open market right now (I tried to buy one), apparently it's sold only to Intel partners under heavy NDAs for evaluation purposes only.

All I was able to find were battery-backed DRAMs with flash for longer-term storage, which is kinda disappointing.

The NOVA filesystem

Posted Aug 7, 2017 12:52 UTC (Mon) by Paf (subscriber, #91811) [Link]

Ah, sorry. I'm drawing my info from public sources, and I thought the reviews meant it was generally available.

That IS disappointing.

The NOVA filesystem

Posted Aug 9, 2017 18:47 UTC (Wed) by iabervon (subscriber, #722) [Link]

The fundamental thing is that emacs communicates to gcc and git by doing one side of a particular set of system calls, and the other ends of this one-to-many-over-time interaction expect to use another set of system calls to retrieve it. Additionally, the system calls have some defined semantics for what the acceptable intermediate states in the source program's sequence to make visible to other programs, including the case where the source program crashes for some reason (not necessarily a power failure).

If you think about the IPC properties of filesystems, it's clear that you need one, even if memory isn't at particular risk from losing power.

The NOVA filesystem

Posted Aug 9, 2017 22:06 UTC (Wed) by zlynx (guest, #2285) [Link]

You can do that if you want. Take a file and mmap it. If NOVA works like tmpfs then writing to the mmap is writing directly into RAM. I haven't checked but I don't see why it would do anything else. Double buffering it would just be silly.