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

From:		Christoph Hellwig <hch-AT-infradead.org>
To:		Jeff Moyer <jmoyer-AT-redhat.com>
Subject:		Re: [RFC 0/2] New MAP_PMEM_AWARE mmap flag
Date:		Mon, 22 Feb 2016 10:03:50 -0800
Message-ID:		<20160222180350.GA9866@infradead.org>
Cc:		Christoph Hellwig <hch-AT-infradead.org>, Dave Chinner <david-AT-fromorbit.com>, Dan Williams <dan.j.williams-AT-intel.com>, Arnd Bergmann <arnd-AT-arndb.de>, linux-nvdimm <linux-nvdimm-AT-ml01.01.org>, Oleg Nesterov <oleg-AT-redhat.com>, linux-mm <linux-mm-AT-kvack.org>, Mel Gorman <mgorman-AT-suse.de>, Johannes Weiner <hannes-AT-cmpxchg.org>, "Kirill A. Shutemov" <kirill.shutemov-AT-linux.intel.com>
Archive‑link:		Article

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>