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>