Hacker News Reader

Comment by nl | Hacker News Reader

It's interesting that the assumptions in the comments here all assume one thinks of this as a disk, as opposed to a non-volatile RAM disk.

No one thinks twice about having to "do something" with their RAM disk to upgrade the CPU.

It's time we realized the new class of nonvolatile memory hardware is a new entry in the storage hierarchy. One shouldn't think of it as RAM, but it's much, much faster than traditional disk (or even SSDs) and should be thought of something different.

It's a mistake to put the same restrictions on the potential performance of this just to make it fit our preconceived notions of storage.

View on HN

Agreed. It is surprisingly hard to lose some of the assumptions spinning rust has left us with. Treating this as a log-structured 'soup', I think, opens up interesting possibilities.

Interop is vital, though. I'm less concerned with being able to pull and seat a drive between machines[1] than sensible replication/backup, and a 'send/receive' type-thing shouldn't be too big of a deal.

[1] Thumb drives are an obvious exception.

I would definitely expect a separate piece of hardware to be swappable without impacting on the rest of my machine. I can change/upgrade the CPU without breaking the north bridge or losing my RAID mapping so why should the data storage mechanism on my new NVMe device (which is where my mind leaps for NOVA) be any different?

What type of usage am I missing where losing/having to do an offline rebuild of your data would be acceptable during a hardware upgrade? NOVA seems to be aiming to address the recognised issue by overprovisioning (which I disagree with but such is life). I don't really understand your argument.

You can't change your CPU without losing the data in RAM (unless you are on zOS), and I think that's a precedent which people are ignoring.

Imagine a hardware architecture which considers NV-RAM as a very large and safe cache, and software which understands that.

This would be great for things like a (huge) RDMS which traditionally requires tables and especially indexes to be in RAM. Suddenly you can get adequate performance on multi-terrabyte indexes, and providing the software understands the storage hierarchy there is no explicit rebuild needed - the data is also stored on spinning rust and on a WAL maybe on a SSD, and will be reloaded into NV-RAM on read.

Reply on news.ycombinator.com