The NOVA filesystem [LWN.net]

The NOVA filesystem

Posted Aug 5, 2017 5:41 UTC (Sat) by alison (subscriber, #63752)
Parent article: The NOVA filesystem

We can all look forward to the day when userspace borks itself, and we reboot to find that userspace is still borked. Perhaps then there will be some kind of intelligent interface allowing operators to go back one snapshot so that the system comes up all the way? I know that some existing FSs have snapshotting features, but don't know how people use them, beyond transferring data between VMs.

Why not just keep a read-only filesystem in the NVM and then bind- or overlay-mount over it? The start-up time while the overlay was read into memory would be longer, but after that, the performance should be great, with little risk of data loss for some applications.

to post comments

The NOVA filesystem

Posted Aug 5, 2017 17:45 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

We can all look forward to the day when userspace borks itself, and we reboot to find that userspace is still borked.

Well, that's exactly what we have in the present day: bork the filesystem, reboot, and it's still going to be borked. NOVA's just another filesystem. Sure, the storage is directly addressable and probably insanely fast, but it's not some fundamentally new abstraction, and the 'bork an important filesystem and reboot will not save you' properly is just the same as it is on present-day filesystems.

The NOVA filesystem

Posted Aug 7, 2017 5:05 UTC (Mon) by alison (subscriber, #63752) [Link]

>bork the filesystem, reboot, and it's still going to be borked.

Sorry for being unclear. I was thinking more that having 'memory' and 'storage on filesystems' as distinct advantages and disadvantages. Blurring the distinction between them will have many consequences, some of which are unpleasant and perhaps unanticipated.