Hi,
On 2020/07/28 11:20, Dave Chinner wrote:
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 understand why the drop_cache operation is necessary. Thanks.
BTW, even normal user becomes to able to change DAX flag for an inode,
drop_cache operation still requires root permission, right?
So, if kernel have a feature for normal user can operate drop cache for
"a inode" with
its permission, I think it improve the above limitation, and
we would like to try to implement it recently.
Do you have any opinion making such feature?
(Agree/opposition, or any other comment?)
Thanks,
--
Yasunori Goto
