From: Dan Williams Subject: Re: [PATCH v2 1/2] fs, xfs: perform dax_device lookup at mount Date: Tue, 29 Aug 2017 14:31:27 -0700 Message-ID: References: <150389211501.25151.6477753201827914462.stgit@dwillia2-desk3.amr.corp.intel.com> <150389212075.25151.17146973298430877023.stgit@dwillia2-desk3.amr.corp.intel.com> <20170829212606.GC8608@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Jan Kara , "Darrick J. Wong" , "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" , linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel , linux-ext4 To: Christoph Hellwig Return-path: In-Reply-To: <20170829212606.GC8608-jcswGhMUV9g@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" List-Id: linux-ext4.vger.kernel.org On Tue, Aug 29, 2017 at 2:26 PM, Christoph Hellwig wrote: > Call me nitpicky, but.. > > First this really should be three patches, one for the DAX code, one > for the VFS code and one for XFS. The DAX and XFS bits looks fine to > me: > > Reviewed-by: Christoph Hellwig > > But I'm a little worried about stuffing more DAX knowledge into the > block mount_bdev helper. For now it's probably ok as everything > else would involve a lot of refactoring and/or duplication, but > I'm generally not too happy about it. I think this is why we ended up with calling dax_get_by_host() in ->iomap_begin() because the mount_bdev() touches I started with back when this was first introduced were not very palatable. I agree with the direction to move to mount_dax() in the future. I can respin this into three patches and a TODO comment about how we want to kill the dax knowledge in mount_bdev() going forward.