The NOVA filesystem [LWN.net]

The NOVA filesystem

Posted Aug 6, 2017 7:43 UTC (Sun) by swanson (guest, #116493)
Parent article: The NOVA filesystem

I'm one of NOVA's designers, and I wanted to clarify one point in the (very nice) article:

NOVA does support DAX mmap. The original paper focused on the atomic mmap mechanism because it was novel (such is the way of research), but normal DAX mmap is fully supported. We received some useful (and not very positive) feedback about atomic mmap from several people, so I'm not sure that atomic mmap is likely to remain a feature.

-steve

to post comments

mmap() + checksum = ?

Posted Aug 7, 2017 13:54 UTC (Mon) by abatters (✭ supporter ✭, #6932) [Link] (1 responses)

> NOVA disables COW for the portions of a file that have been mapped into a process's address space, so changes are made in place.

> There are a number of self-protection measures built into NOVA, including checksumming for data and metadata.

If you mmap() the storage as memory and write to it in-place from the CPU, that would invalidate the data checksum. If the system crashes at that point, what happens to the file with invalid checksum after the system reboots?

mmap() + checksum = ?

Posted Aug 15, 2017 17:58 UTC (Tue) by swanson (guest, #116493) [Link]

This is an interesting problem.

The approach that NOVA takes is to disable parity/checksum protection while data is mmap'd and re-enable it when the mapping is finished. We track overlapping maps etc., and we have log mmap operations so we can re-enable protection after reboot.

The reasoning for this approach is that when you use DAX-mmap() you take responsibility for your data. This includes responsibility for updating it consistently and responsibility for protecting it from media errors, etc. As you point out, the file system really can't fill this role (at least not without a significant performance penalty), so it must fall to the application.

-steve