On Wed, Apr 08, 2020 at 02:28:30PM -0700, Dan Williams wrote: > On Wed, Apr 8, 2020 at 2:02 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > THis leads to an obvious conclusion: if we never clear the in memory > > S_DAX flag, we can actually clear the on-disk flag safely, so that > > next time the inode cycles into memory it won't be using DAX. IOWs, > > admins can stop the applications, clear the DAX flag and drop > > caches. This should result in the inode being recycled and when the > > app is restarted it will run without DAX. No ned for deleting files, > > copying large data sets, etc just to turn off an inode flag. > > Makes sense, but is that sufficient? I recall you saying there might > be a multitude of other reasons that the inode is not evicted, not the > least of which is races [1]. Does this need another flag, lets call it > "dax toggle" to track the "I requested the inode to clear the flag, > but on cache-flush + restart the inode never got evicted" case. You mean something like XFS_IDONTCACHE? i.e. the functionality already exists in XFS to selectively evict an inode from cache when the last reference to it is dropped rather than let it go to the LRUs and hang around in memory. That flag can be set when changing the on disk DAX flag, and we can tweak how it works so new cache hits don't clear it (as happens now). Hence the only thing that can prevent eviction are active references. That means we'll still need to stop the application and drop_caches, because we need to close all the files and purge the dentries that hold references to the inode before it can be evicted. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
