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:

quoted

On Fri, Oct 25, 2019 at 01:49:26PM -0700, Ira Weiny wrote:

[snip]

quoted

quoted

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.

quoted

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@fromorbit.com