Andiry Xu (working with Lu Zhang,
Steven Swanson and others) posted
patches for a new filesystem called NOVA (NOn-Volatile
Normal RAM chips are wiped every time you turn off your
computer. Non-volatile RAM retains its data across reboots. Their project
targeted byte-addressable non-volatile memory chips, such as
3DXpoint DIMMs. Andiry said that the current incarnation of their code was
able to do a lot already, but they still had a big to-do list, and they
wanted feedback from the kernel people.
Theodore Y. Ts’o gave the patches a try, but he found that they wouldn’t even
compile without some fixes, which he posted in reply. Andiry said they’d
adapt those fixes into their patches.
The last time NOVA made an appearance on the kernel mailing list was August
2017, when Steven made a similar announcement. This time around, they
posted a lot more patches, including support for SysFS
compilation options and a significant amount of documentation.
One of NOVA’s main claims to fame, aside from supporting non-volatile RAM,
is that it is a log-based filesystem. Other filesystems generally map out
their data structures on disk and update those structures in place. This
is good for saving seek-time on optical and magnetic disks. Log-based filesystems write everything sequentially, trailing old data behind them. The
old data then can be treated as a snapshot of earlier states of the filesystem, or it can be reclaimed when space gets tight.
Log-based filesystems are not necessarily preferred for optical and
magnetic drives, because sequential writes will tend to fragment data and
slow things down. Non-volatile RAM is based on different technology that
has faster seek-times, making a log-based approach a natural choice.
NOVA goes further than most log-based filesystems, which tend to have a
single log for the whole filesystem, and instead maintains a separate log
for each inode. Using the log data, NOVA can perform writes either in place
like traditional filesystems or as copy-on-write (COW) operations, which
keep the old version of a file until the new version has been written. This
has the benefit of being able to survive catastrophic events like sudden
power failures in the middle of doing a write, without corrupting the filesystem.
There were lots of responses to the patches from Andiry and the rest of his
team. Most were bug reports and criticism, but no controversy. Everyone
seemed to be interested in helping them get their code right so the patches
could get into the main tree quickly.
Note: if you’re mentioned above and want to post a response above the comment section, send a message with your response text to email@example.com.
Powered by WPeMatico