Re: [RFC 0/2] New MAP_PMEM_AWARE mmap flag

[Christoph Hellwig <hch@infradead.org>]

On Mon, Feb 22, 2016 at 10:34:45AM -0500, Jeff Moyer wrote:
> > 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.

> > 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>