From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.177]) by kanga.kvack.org (Postfix) with ESMTP id 2A5C682F69 for ; Mon, 22 Feb 2016 13:03:53 -0500 (EST) Received: by mail-pf0-f177.google.com with SMTP id q63so96315196pfb.0 for ; Mon, 22 Feb 2016 10:03:53 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id ze7si36639793pac.34.2016.02.22.10.03.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Feb 2016 10:03:52 -0800 (PST) Date: Mon, 22 Feb 2016 10:03:50 -0800 From: Christoph Hellwig Subject: Re: [RFC 0/2] New MAP_PMEM_AWARE mmap flag Message-ID: <20160222180350.GA9866@infradead.org> References: <56C9EDCF.8010007@plexistor.com> <56CA1CE7.6050309@plexistor.com> <56CA2AC9.7030905@plexistor.com> <20160221223157.GC25832@dastard> <20160222174426.GA30110@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Jeff Moyer Cc: Christoph Hellwig , Dave Chinner , Dan Williams , Arnd Bergmann , linux-nvdimm , Oleg Nesterov , linux-mm , Mel Gorman , Johannes Weiner , "Kirill A. Shutemov" 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: email@kvack.org