On Thu, Sep 07, 2017 at 03:51:48PM -0600, Ross Zwisler wrote: > On Thu, Sep 07, 2017 at 03:26:10PM -0600, Andreas Dilger wrote: > > However, I wonder if this could > > be prevented at runtime, and only allow S_DAX to be set when the inode is > > first instantiated, and wouldn't be allowed to change after that? Setting > > or clearing the per-inode DAX flag might still be allowed, but it wouldn't > > be enabled until the inode is next fetched into cache? Similarly, for > > inodes that have conflicting features (e.g. inline data or encryption) > > would not be allowed to enable S_DAX. > > Ooh, this seems interesting. This would ensure that S_DAX transitions > couldn't ever race with I/Os or mmaps(). I had some other ideas for how to > handle this, but I think your idea is more promising. :) IMO, that's an awful admin interface - it can't be done on demand (i.e. when needed) because we can't force an inode to be evicted from the cache. And then we have the "why the hell did that just change" problem if an inode is evicted due to memory pressure and then immediately reinstantiated by the running workload. That's a recipe for driving admins insane... > I guess with this solution we'd need: > > a) A good way of letting the user detect the state where they had set the DAX > inode flag, but that it wasn't yet in use by the inode. > > b) A reliable way of flushing the inode from the filesystem cache, so that the > next time an open() happens they get the new behavior. The way I usually do > this is via umount/remount, but there is probably already a way to do this? Not if it's referenced. And if it's not referenced, then the only hammer we have is Brutus^Wdrop_caches. That's not an option for production machines. Neat idea, but one I'd already thought of and discarded as "not practical from an admin perspective". Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
