From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from newverein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id F37AE81ECF for ; Sun, 22 Jan 2017 10:30:48 -0800 (PST) Date: Sun, 22 Jan 2017 19:30:46 +0100 From: Christoph Hellwig Subject: Re: [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm Message-ID: <20170122183046.GA7359@lst.de> References: <148488421301.37913.12835362165895864897.stgit@dwillia2-desk3.amr.corp.intel.com> <20170121175212.GA28180@lst.de> <20170122162910.GA5267@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Matthew Wilcox Cc: Jens Axboe , Tony Luck , Jan Kara , Mike Snitzer , "linux-nvdimm@lists.01.org" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Ingo Molnar , Thomas Gleixner , Al Viro , "H. Peter Anvin" , "linux-fsdevel@vger.kernel.org" , "dm-devel@redhat.com" , Linus Torvalds , Christoph Hellwig List-ID: On Sun, Jan 22, 2017 at 06:19:24PM +0000, Matthew Wilcox wrote: > No, I mean a network filesystem like 9p or cifs or nfs. If the memcpy > is supposed to be performed by the backing device struct backing_dev has no relation to the DAX code. Even more so what's the point of doing a DAXish memcpy in that case? If we buffer in memory for network I/O we should just use the page cache. > (Also, the network filesystem might have a command, like RDMA has/will have, to ensure that the write has reached persistence) I know very well due to my work for a DAX-backed pNFS layout. But that is mostly transparent to the NFS frontend code and won't use DAX on the client at all. Just pagecache as a source for RDMA READ/WRITE. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm