
The NOVA filesystem - JoshTriplett
https://lwn.net/SubscriberLink/729812/1557fcd18e4dd96f/
======
ecma
This is super interesting but

    
    
       due to the per-CPU inode table
       structure, it is impossible to
       move a NOVA filesystem from one
       system to another if the two
       machines do not have the same
       number of CPUs.
    

seems like a dealbreaker. What use is a FS if it isn't portable? At least it
sounds like they're very aware of this issue.

I'd be very interested to see what they end up doing to make this behave
better prior to upstream consideration. I wonder if a linked list journal of
inode table changes (with space drawn from per-CPU freelists) would be
safe/fast enough. That could be periodically coalesced and remapped to the
NOVA device's non-CPU aware inode table.

~~~
microcolonel
I don't see it as such a big problem. Most filesystem images aren't intended
to be ported directly between machines in general. As long as they have a tool
to read the filesystem on a different configuration, a filesystem with this
restriction could still be very useful for generic bulk storage on a single
node.

~~~
pantalaimon
What if you upgrade the machine with a new CPU that has more cores?

~~~
pixl97
Disable some cores in the bios.

~~~
loeg
That sort of defeats the point of an upgrade.

~~~
pixl97
So going from 2GHz to 3, or getting 50÷ IPC from an updated chip isn't worth
it?

------
nl
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.

~~~
ecma
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.

~~~
nl
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.

