Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4647016ybb; Tue, 7 Apr 2020 11:32:37 -0700 (PDT) X-Google-Smtp-Source: APiQypIlmBf5fpaoC+1w92y7LpG4Ig6C4rRXUKEwxs8vXYBv+Xm9uZronbKfAV9MTfUCvfNaDBsX X-Received: by 2002:a4a:3306:: with SMTP id q6mr2950401ooq.81.1586284357089; Tue, 07 Apr 2020 11:32:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586284357; cv=none; d=google.com; s=arc-20160816; b=yIdwg55+ADVfReVu0wkv825bVRm5htCO4dAknlnccjuyPjelV9tv4GrlfmRZec51sr XoU5NA+m6v0x4ifNlbluw601rjLv80FEb7cHkXQ2oAmQuvgjTodBkJF5ZdqIViulKiKv CRdiB842tTjsoUh5a4Z1NNh8i1Bjctaj71mQnAmvnWWKwfbt3zi0qsTAOfchUy1Nh3tS z/3+IDX67lV/8WruSjyHczIvmFuEgln7ddf8mIIEzM3NFAE8LRZzB3BrzyOKY7V+edL7 sh9m3pkx3p5m7UbsiLNsaqrPNl31DWV3Th7P6DbBAlPyaZW1oMkj/8whQqwPMBIafx2c AB2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :ironport-sdr:ironport-sdr; bh=xk9gIll+oHIqYfct7FUDGdfwdxsKR9sjjXknWd42yXU=; b=HFSQGMrxhjdnjxYKzeflwznRpeVEvAZs7iTA8yLz8WnIeUL6rneYG4hQDVULRg9wvV mK55KFQnVwfpMEoxzERyCh3ZXvx83pcS7beOBACoe7T2YOaWdGdueSYOTmeG5YiMrT/H XSoX/aIqIdEN0QGtN2Ak6u5D/CosVdoza5CQdblFTUAxk97tnylPI8f0xtgCFWgF9C25 TQQBB54F3rx7yQuMsbY42WOY3ZGUddAw04dvtw2YVmzEX6M97Qzcz9iKlhvvA4fT6d6m oV+eg8FoNqtyoBouiavXVj0zFl5j1wm+9lLmI6DnOD8q7rR+MyZFXbiSCSPTUNHMBXDT Lx+g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 131si976728oid.75.2020.04.07.11.32.23; Tue, 07 Apr 2020 11:32:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726795AbgDGSan (ORCPT + 99 others); Tue, 7 Apr 2020 14:30:43 -0400 Received: from mga14.intel.com ([192.55.52.115]:60147 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726701AbgDGSah (ORCPT ); Tue, 7 Apr 2020 14:30:37 -0400 IronPort-SDR: 6Az7K4hsn4ap01ZCWKsHK7hfjgc9LkXTAjjiFV4ofLYslvXjJAQQxd7G3E9I7+ZpLyAFnTQ2Jx nBGtWFJeJXEA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2020 11:30:36 -0700 IronPort-SDR: fOz7VX96+8SYFwmfOpMAPO9gL2srNCtndIiprKfwKQtJkSjHuBt2/7zQF+frsSNgc44re4rk/3 wJuq4rc8KqNw== X-IronPort-AV: E=Sophos;i="5.72,356,1580803200"; d="scan'208";a="240039465" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.147]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2020 11:30:36 -0700 From: ira.weiny@intel.com To: linux-kernel@vger.kernel.org Cc: Ira Weiny , "Darrick J. Wong" , Dan Williams , Dave Chinner , Christoph Hellwig , "Theodore Y. Ts'o" , Jan Kara , Jeff Moyer , linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: [PATCH V6 8/8] Documentation/dax: Update Usage section Date: Tue, 7 Apr 2020 11:29:58 -0700 Message-Id: <20200407182958.568475-9-ira.weiny@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200407182958.568475-1-ira.weiny@intel.com> References: <20200407182958.568475-1-ira.weiny@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org From: Ira Weiny Update the Usage section to reflect the new individual dax selection functionality. Signed-off-by: Ira Weiny --- Changes from V5: Update to reflect the agreed upon semantics https://lore.kernel.org/lkml/20200405061945.GA94792@iweiny-DESK2.sc.intel.com/ --- Documentation/filesystems/dax.txt | 94 ++++++++++++++++++++++++++++++- 1 file changed, 91 insertions(+), 3 deletions(-) diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt index 679729442fd2..d84e8101cf8a 100644 --- a/Documentation/filesystems/dax.txt +++ b/Documentation/filesystems/dax.txt @@ -17,11 +17,99 @@ For file mappings, the storage device is mapped directly into userspace. Usage ----- -If you have a block device which supports DAX, you can make a filesystem +If you have a block device which supports DAX, you can make a file system on it as usual. The DAX code currently only supports files with a block size equal to your kernel's PAGE_SIZE, so you may need to specify a block -size when creating the filesystem. When mounting it, use the "-o dax" -option on the command line or add 'dax' to the options in /etc/fstab. +size when creating the file system. + +Enabling DAX on an individual file basis (XFS) +---------------------------------------------- + +There are 2 per file dax flags. One is a physical inode setting (FS_XFLAG_DAX) and +the other a currently enabled state (S_DAX). + +FS_XFLAG_DAX is maintained on individual file and directory inodes. It is +preserved within the file system. This 'physical' config setting can be set on +directories using an ioctl and/or an application such as "xfs_io -c 'chattr +[-+]x'". Files and directories automatically inherit FS_XFLAG_DAX from their +parent directory _when_ _created_. Therefore, setting FS_XFLAG_DAX at +directory creation time can be used to set a default behavior for an entire +sub-tree. (Doing so on the root directory acts to set a default for the entire +file system.) + +To clarify inheritance here are 3 examples: + +Example A: + +mkdir -p a/b/c +xfs_io 'chattr +x' a +mkdir a/b/c/d +mkdir a/e + + dax: a,e + no dax: b,c,d + +Example B: + +mkdir a +xfs_io 'chattr +x' a +mkdir -p a/b/c/d + + dax: a,b,c,d + no dax: + +Example C: + +mkdir -p a/b/c +xfs_io 'chattr +x' c +mkdir a/b/c/d + + dax: c,d + no dax: a,b + + +The current enabled state (S_DAX) is set when a file inode is loaded based on +the underlying media support and the file systems dax mount option setting. See +below. + +statx can be used to query S_DAX. NOTE that a directory will never have S_DAX +set and therefore statx will always return false. FS_XFLAG_DAX can be queried +with ioctl or xfs_io on directories. + +NOTE: Setting FS_XFLAG_DAX on a directory is possible even if the underlying +media does not support dax. Furthermore, files and directories will continue +to inherit FS_XLFAG_DAX even if the underlying media does not support dax. + + +overriding FS_XFLAG_DAX (the dax= mount option) +----------------------------------------------- + +The dax mount option is a tri-state option (never, always, iflag): + + "-o dax=never" means "never set S_DAX, ignore FS_XFLAG_DAX" + "-o dax=always" means "always set S_DAX (at least on pmem), ignore FS_XFLAG_DAX" + "-o dax" by itself means "dax=always" to remain compatible with older + kernels + "-o dax=iflag" means "follow FS_XFLAG_DAX" + +The default state is 'iflag'. The following algorithm is used to determine the +effective mode of the file S_DAX on a capable device. + + S_DAX &= FS_XFLAG_DAX; + + if (dax_mount == "always") + S_DAX = true; + else if (dax_mount == "off" + S_DAX = false; + +Using the mount option does not change the physical configured state of +individual files. + +NOTE: Setting FS_XFLAG_DAX on a directory is possible while the file system is +mounted with the dax override. In addition, files and directories will inherit +FS_XFLAG_DAX as normal while the file system is overriden. However, the file's +enabled state will continue to be the mount option until remounted with +dax=iflag. Implementation Tips for Block Driver Writers -- 2.25.1