On Mon, Oct 28, 2019 at 09:10:39AM +1100, Dave Chinner wrote: > On Fri, Oct 25, 2019 at 01:49:26PM -0700, Ira Weiny wrote: [snip] > > > Currently this works if I remount the fs or if I use <procfs>/drop_caches like > > Boaz mentioned. > > drop_caches frees all the dentries that don't have an active > references before it iterates over inodes, thereby dropping the > cached reference(s) to the inode that pins it in memory before it > iterates the inode LRU. > > > Isn't there a way to get xfs to do that on it's own? > > Not reliably. Killing all the dentries doesn't guarantee the inode > will be reclaimed immediately. The ioctl() itself requires an open > file reference to the inode, and there's no telling how many other > references there are to the inode that the filesystem a) can't find, > and b) even if it can find them, it is illegal to release them. > > IOWs, if you are relying on being able to force eviction of inode > from the cache for correct operation of a user controlled flag, then > it's just not going to work. Agree, I see the difficulty of forcing the effective flag to change in this path. However, the only thing I am relying on is that the ioctl will change the physical flag. IOW I am proposing that the semantic be that changing the physical flag does _not_ immediately change the effective flag. With that clarified up front the user can adjust accordingly. After thinking about this more I think there is a strong use case to be able to change the physical flag on a non-zero length file. That use case is to be able to restore files from backups. Therefore, having the effective flag flip at some later time when the a_ops can safely be changed (for example a remount/drop_cache event) is beneficial. I propose the user has no direct control over this event and it is mainly used to restore files from backups which is mainly an admin operation where a remount is a reasonable thing to do. Users direct control of the effective flag is through inheritance. The user needs to create the file in a DAX enable dir and they get effective operation right away. If in the future we can determine a safe way to trigger the a_ops change we can add that to the semantic as an alternative for users. Ira > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
