From: Dave Chinner <david@fromorbit.com>
To: "Li, Hao" <lihao2018.fnst@cn.fujitsu.com>
Cc: "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"ira.weiny@intel.com" <ira.weiny@intel.com>,
"Gotou, Yasunori" <y-goto@fujitsu.com>
Subject: Re: Can we change the S_DAX flag immediately on XFS without dropping caches?
Date: Tue, 28 Jul 2020 12:20:59 +1000 [thread overview]
Message-ID: <20200728022059.GX2005@dread.disaster.area> (raw)
In-Reply-To: <9dc179147f6a47279d801445f3efeecc@G08CNEXMBPEKD04.g08.fujitsu.local>
On Tue, Jul 28, 2020 at 02:00:08AM +0000, Li, Hao wrote:
> Hi,
>
> I have noticed that we have to drop caches to make the changing of S_DAX
> flag take effect after using chattr +x to turn on DAX for a existing
> regular file. The related function is xfs_diflags_to_iflags, whose
> second parameter determines whether we should set S_DAX immediately.
Yup, as documented in Documentation/filesystems/dax.txt. Specifically:
6. When changing the S_DAX policy via toggling the persistent FS_XFLAG_DAX flag,
the change in behaviour for existing regular files may not occur
immediately. If the change must take effect immediately, the administrator
needs to:
a) stop the application so there are no active references to the data set
the policy change will affect
b) evict the data set from kernel caches so it will be re-instantiated when
the application is restarted. This can be achieved by:
i. drop-caches
ii. a filesystem unmount and mount cycle
iii. a system reboot
> I can't figure out why we do this. Is this because the page caches in
> address_space->i_pages are hard to deal with?
Because of unfixable races in the page fault path that prevent
changing the caching behaviour of the inode while concurrent access
is possible. The only way to guarantee races can't happen is to
cycle the inode out of cache.
> I also wonder what will
> happen if we set S_DAX unconditionally. Thanks!
As per the documentation, that's exactly what the dax=always mount
option does.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2020-07-28 2:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 2:00 Can we change the S_DAX flag immediately on XFS without dropping caches? Li, Hao
2020-07-28 2:20 ` Dave Chinner [this message]
2020-07-29 2:23 ` Yasunori Goto
2020-07-29 16:10 ` Ira Weiny
2020-07-31 9:12 ` Li, Hao
2020-08-05 8:10 ` Li, Hao
2020-08-05 15:44 ` Darrick J. Wong
2020-08-07 16:57 ` Ira Weiny
2020-07-31 10:04 ` Yasunori Goto
2020-07-29 23:21 ` Dave Chinner
2020-07-31 9:15 ` Li, Hao
2020-07-31 9:59 ` Yasunori Goto
2020-08-07 17:09 ` Ira Weiny
2020-08-18 9:16 ` Li, Hao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200728022059.GX2005@dread.disaster.area \
--to=david@fromorbit.com \
--cc=ira.weiny@intel.com \
--cc=lihao2018.fnst@cn.fujitsu.com \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-xfs@vger.kernel.org \
--cc=y-goto@fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).