Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751522AbdGZTQO (ORCPT ); Wed, 26 Jul 2017 15:16:14 -0400 Received: from mail-yw0-f178.google.com ([209.85.161.178]:36106 "EHLO mail-yw0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750970AbdGZTQM (ORCPT ); Wed, 26 Jul 2017 15:16:12 -0400 MIME-Version: 1.0 In-Reply-To: <20170726172011.GA30142@infradead.org> References: <1500552639-18523-1-git-send-email-sunqiuyang@huawei.com> <20170726072634.GA4684@infradead.org> <20170726170147.GA31930@infradead.org> <20170726172011.GA30142@infradead.org> From: Dan Williams Date: Wed, 26 Jul 2017 12:16:11 -0700 Message-ID: Subject: Re: [PATCH v8 1/1] f2fs: dax: implement direct access To: Christoph Hellwig Cc: "linux-nvdimm@lists.01.org" , Linux Kernel Mailing List , linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel , Jaegeuk Kim , sunqiuyang Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1412 Lines: 29 On Wed, Jul 26, 2017 at 10:20 AM, Christoph Hellwig wrote: > On Wed, Jul 26, 2017 at 10:11:08AM -0700, Dan Williams wrote: >> Until HMAT came along we had no data in the kernel how to pick a sane >> default, but we could now very easily make a "if pmem performance < >> dram, disable dax by default" policy in the kernel. > > I'd rather do it the other way around - if HMAT is present and > pmem performance >= dram use dax. Else require the explicit -o dax > for now to enable it. If an explicit -o nodax is specified disable > DAX even if HMAT says it is faster. Silently turn on DAX if HMAT says its ok? I think we would instead want a "-o autodax" for that case and then "-o dax" and "-o nodax" for the force cases. >> The question for this patch is do we want to add yet another >> filesystem that adds "-o dax" or require use of per-inode flags to >> enable dax. > > Please stick to the mount option. After spending a lot of time with > DAX and various memory techologies I'm pretty confident that the inode > flag is the wrong thing to do. I think it's easier to administer than the dax mount option. If someone wants dax on only in a sub-tree they can set the flag on that parent directory and have a policy in dax filesystems that children inherit the dax policy from the parent. That seems a better administrative model than trying to get it all right globally at mount time.