On Thu, Apr 09, 2020 at 09:58:36AM +1000, Dave Chinner wrote: > 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. That sounds like a great idea... Jan? Christoph? I will reiterate though that any delayed S_DAX change be done as a follow on series to the one proposed here. Ira
