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

[Jeff Moyer <jmoyer@redhat.com>]

Hi, Christoph,

Christoph Hellwig <hch@infradead.org> writes:

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

Right, I meant after fault, but it seems like you're suggesting that
that is even possible.  I wouldn't mind discussing this part more, but I
think it detracts from the main question I have, which is at the end.
Maybe we can take it up over beers some time.

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

Duh, yeah.  I forgot about the "metadata necessary to find the file
data" part (which is, admittedly, a big part).

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

Sorry for being dense, but why, exactly?  If the file system is making
changes without the application's involvement, then the file system
should be responsible for ensuring its own consistency, irrespective of
whether the application issues an fsync.  Clearly I'm missing some key
point here.

-Jeff

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