On Mon, Feb 22, 2016 at 10:34:45AM -0500, Jeff Moyer wrote:

quoted

of the application and so file metadata changes may still be in
volatile RAM even though the application has flushed it's data.

Once you hand out a persistent memory mapping, you sure as heck can't
switch blocks around behind the back of the application.

You might not even have allocated the blocks at the time of the mmap,
although for pmem remapping it after a page fault has actually allocated
the block would be rather painful.

But even if we're not dealing with persistent memory, you seem to imply
that applications needs to fsync just in case the file system did
something behind its back.  In other words, an application opening a
fully allocated file and using fdatasync will also need to call fsync,
just in case.  Is that really what you're suggesting?

You above statement looks rather confused.  The only difference between
fdatasync and sync is that the former does not write out metadata not
required to find the file data (usually that's just timestamps).  So if
you already use fdatasync or msync properly you don't need to fsync
again.  But you need to use one of the above methods to ensure your
data is persistent on the medium.

quoted

Applications have no idea what the underlying filesystem and storage
is doing and so they cannot assume that complete data integrity is
provided by userspace driven CPU cache flush instructions on their
file data.

This is surprising to me, and goes completely against the proposed
programming model.  In fact, this is a very basic tenet of the operation
of the nvml libraries on pmem.io.

It's simply impossible to provide.  But then again pmem.io seems to be
much more about hype than reality anyway.

An application creates a file and writes to every single block in the
thing, sync's it, closes it.  It then opens it back up, calls mmap with
this new MAP_DAX flag or on a file system mounted with -o dax, and
proceeds to access the file using loads and stores.  It persists its
data by using non-temporal stores, flushing and fencing cpu
instructions.

If I understand you correctly, you're saying that that application is
not written correctly, because it needs to call fsync to persist
metadata (that it presumably did not modify).  Is that right?

Exactly.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>