From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 3/5] block: Add support for DAX on block devices Date: Wed, 1 Jul 2015 00:19:15 -0700 Message-ID: <20150701071915.GA31381@infradead.org> References: <1435608152-6982-1-git-send-email-matthew.r.wilcox@intel.com> <1435608152-6982-4-git-send-email-matthew.r.wilcox@intel.com> <20150630111949.GA28508@infradead.org> <20150630195614.GG1971@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Matthew Wilcox , linux-fsdevel@vger.kernel.org, Alexander Viro To: Matthew Wilcox Return-path: Received: from bombadil.infradead.org ([198.137.202.9]:58400 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751230AbbGAHTQ (ORCPT ); Wed, 1 Jul 2015 03:19:16 -0400 Content-Disposition: inline In-Reply-To: <20150630195614.GG1971@linux.intel.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Jun 30, 2015 at 03:56:15PM -0400, Matthew Wilcox wrote: > > Using O_DIRECT for this seems like a pretty horrible hack, so I'd like > > to see a really good justification of using this over other interfaces. > > O_DIRECT means "bypass the page cache", which is what this does (now it's > able to apply to mmap too). It never had a meaning for mmap. > > Also it needs a Cc to linux-api and an entry in the open man page, and > > and even better explanation of why we only support this interface on > > block devices but not file systems. > > Um, we do support this for filesystems with DAX. The inconsistency we > have is that if you have a direct-access-capable block device, currently > files in a filesystem on it get the bypass-page-cache treatment, but if > you use the raw block device directly, that mapping doesn't. I don't see this O_DIRECT check done anywhere in filesystems. Filesystems seems to get your O_DIRECT treatment when mounted with the dax option as far as I can tell without the need for additional options. The block device equivalent would be a sysfs flag, which seems like the better implementation choice here.