On Wed, Apr 08, 2020 at 03:26:36PM -0700, Ira Weiny wrote: > On Thu, Apr 09, 2020 at 07:09:50AM +1000, Dave Chinner wrote: > > On Wed, Apr 08, 2020 at 11:58:03AM +0200, Jan Kara wrote: > > I explained how we can safely remove the flag in the other branch of > > this thread... > > > > > But it seems like more understandable API than letting user clear > > > the on-disk flag but the inode will still use DAX until kernel decides to > > > evict the inode > > > > Certainly doesn't seem that way to me. "stop app, clear flags, drop > > caches, restart app" is a pretty simple, easy thing to do for an > > admin. > > I want to be clear here: I think this is reasonable. However, I don't see > consensus for that interface. > > Christoph in particular said that a 'lazy change' is: "... straight from > the playbook for arcane and confusing API designs." > > "But returning an error and doing a lazy change anyway is straight from > the playbook for arcane and confusing API designs." > > -- https://lore.kernel.org/lkml/20200403072731.GA24176@xxxxxx/ > > Did I somehow misunderstand this? Yes. Clearing the on-disk flag successfully should not return an error. What is wrong is having it clear the flag successfully and returning an error because the operation doesn't take immediate effect, then having the change take effect later after telling the application there was an error. That's what Christoph was saying is "straight from the playbook for arcane and confusing API designs." There's absolutely nothing wrong with setting/clearing the on-disk flag and having the change take effect some time later depending on some external context. We've done this sort of thing for a -long time- and it's not XFS specific at all. e.g. changing the on-disk APPEND flag doesn't change the write behaviour of currently open files - it only affects the behaviour of future file opens. IOWs, we can have the flag set on disk, but we can still write randomly to the inode as long as we have a file descriptor that was opened before the APPEND on disk flag was set. That's exactly the same class of behaviour as we are talking about here for the on-disk DAX flag. > > Especially compared to process that is effectively "stop app, backup > > data set, delete data set, clear flags, restore data set, restart > > app" > > > > > - because that often means you need to restart the > > > application using the file anyway for the flag change to have any effect. > > > > That's a trivial requirement compared to the downtime and resource > > cost of a data set backup/restore just to clear inode flags.... > > I agree but others do not. This still provides a baby step forward and some It's not a baby step forward. We can't expose a behaviour to userspace and then decide to change it completely at some later date. We have to think through the entire admin model before setting it in concrete. If an admin operation can set an optional persistent feature flags on a file, then there *must* be admin operations that can remove that persistent feature flag from said files. This has *nothing to do with DAX* - it's a fundamental principle of balanced system design. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
