Thread (2 messages) 2 messages, 2 authors, 2016-02-22

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

From: Christoph Hellwig <hch@infradead.org>
Date: 2016-02-22 18:03:53

On Mon, Feb 22, 2016 at 12:58:18PM -0500, Jeff Moyer wrote:
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.
The simplest example is a copy on write file system (or simply a copy on
write file, which can exist with ocfs2 and will with xfs very soon),
where each write will allocate a new block, which will require metadata
updates.

We've built the whole I/O model around the concept that by default our
I/O will required fsync/msync.  For read/write-style I/O you can opt out
using O_DSYNC.  There currently is no way to opt out for memory mapped
I/O, mostly because it's

  a) useless without something like DAX, and
  b) much harder to implement

So a MAP_SYNC option might not be entirely off the table, but I think
it would be a lot of hard work and I'm not even sure it's possible
to handle it in the general case.

--
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help