Hacker News new | ask | show | jobs
by Animats 4236 days ago
Computing really hasn't figured out how to handle non-volatile memory as yet. It's almost always used to emulate rotating disks, with file systems, named files, and a trip through the OS to access anything. Access times for non-volatile memory are orders of magnitude faster than disk access times, so small accesses are feasible. But that's not how it's treated under existing operating systems.

There are alternatives. Non-volatile memory could be treated as a key/value store, or a tree, with a storage controller between the CPU and the memory device. With appropriate protection hardware, this could be accessed from user space through special instructions. That's what I though this article indicated. But no. This is just better cache management for the OS.

6 comments

There have been systems where everything is memory mapped and disks are just used to emulate more memory.

It's called "single-level store" in System 36 and descendants. File access in Multics was all memory mapped.

There's nothing inherently rotating-disky about current filesystem APIs from the user point of view, a they just provide a database interface which has a certain type of namespace system for access. The block level part is largely invisible to the FS users (modulo leaky abstractions).

It is already treated as a k/v store, where key is a LBA and the value is a 512/4096byte block. The OS builds everything else (ie. filesystems) on top of that. Applications can already now access the raw k/v store directly if they wish (open /dev/sd? directly, permissions allowing).
This is not (specifically) for the OS. This is for non-volatile memory that is directly attached to the memory bus. The OS can then directly map NVRAM into the address space of a user-space process; the application could use these instructions to efficiently ensure the crash consistency of its persistent data.
Well, this is about userspace access to nvram, with the nvram mapped as memory. It just so happens that cache management is one of the hard parts of doing that, so that's what these new instructions are for.
Don't forget core memory existed before rotating disks. The first internet routers were shipped with their program already loaded.
Can't use current flash chips in that way, because write endurance.
Also, current Flash memories do not allow single address writes. At least the write endurance problem could be addressed by adding write leveling to an address translation layer. The single address thing could be addressed by a caching/grouping layer that could interact with the leveling mechanisms. Add to that an all-core state dump to a block write and you can recover to an internally consistent state after a power failure.