[RFC v2] nvfs: a filesystem for persistent memory
From: Mikulas Patocka
Date: Thu Jan 07 2021 - 08:17:33 EST
I announce a new version of NVFS - a filesystem for persistent memory.
Changes since the last release:
* I added a microjournal to the filesystem, it can hold up to 16 entries.
Each CPU has it's own journal, so that there is no lock contention. The
journal is used to provide atomicity of reaname() and extended attribute
(note that file creation or deletion doesn't use the journal, because
these operations can be deterministically cleaned up by fsck)
* I created a framework that can be used to verify the filesystem driver.
It logs all writes and memory barriers to a file, the entries in the
file are randomly reordered (to simulate reordering in the CPU
write-combining buffers), the sequence is cut at a random point (to
simulate a system crash) and the result is replayed on a filesystem
With this framework, we can for example check that if a crash happens
during rename(), either old file or new file will be present in a
This framework helped to find a few bugs in sequencing the writes.
* If we map an executable image, we turn off the DAX flag on the inode
(because executables run 4% slower from persistent memory). There is
also a switch that can turn DAX always off or always on.
I'd like to ask about this piece of code in __kernel_read:
if (unlikely(!file->f_op->read_iter || file->f_op->read))
if (unlikely(!file->f_op->write_iter || file->f_op->write))
- It exits with an error if both read_iter and read or write_iter and
write are present.
I found out that on NVFS, reading a file with the read method has 10%
better performance than the read_iter method. The benchmark just reads the
same 4k page over and over again - and the cost of creating and parsing
the kiocb and iov_iter structures is just that high.
So, I'd like to have both read and read_iter methods. Could the above
conditions be changed, so that they don't fail with an error if the "read"
or "write" method is present?