On Thu, Oct 31, 2019 at 09:17:58AM -0700, Ira Weiny wrote: > 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. Which makes it useless from an admin perspective. i.e. to change the way the application uses DAX now, admins are going to have to end up rebooting the machine to guarantee that the kernel has picked up the change in the on-disk flag. > 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. Why does that matter? Backup programs need to set the flag before the data is written into the destination file, just like they do with restoring other flags that influence data placement like the RT device bit and extent size hints... Basically, all these issues you keep trying to work around go away if we can come up with a way of swapping the aops vector safely. That's the problem we need to solve, anything else results in largely unacceptible user visible admin warts. > 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. As soon as users understand that they flag can be changed, they are going to want to do that and they are going to want it to work reliably. > 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. Until they realise the application is slow or broken because it is using DAX, and they want to turn DAX off for that application. Then they have *no control*. You cannot have it both ways - being able to turn something on but not turn it off is not "effective operation" or user friendly. > 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. No, the flag does not get turned on until we've solved the problems that resulted in us turning it off. We've gone over this mutliple times, and nobody has solved the issues that need solving - everyone seems to just hack around the issues rather than solving it properly. If we thought taking some kind of shortcut full of compromises and gotchas was the right solution, we would have never turned the flag off in the first place. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
