On Fri, Apr 03, 2020 at 09:27:31AM +0200, Christoph Hellwig wrote: > On Thu, Apr 02, 2020 at 01:55:19PM -0700, Ira Weiny wrote: > > > I'd just return an error for that case, don't play silly games like > > > evicting the inode. > > > > I think I agree with Christoph here. But I want to clarify. I was heading in > > a direction of failing the ioctl completely. But we could have the flag change > > with an appropriate error which could let the user know the change has been > > delayed. > > > > But I don't immediately see what error code is appropriate for such an > > indication. Candidates I can envision: > > > > EAGAIN > > ERESTART > > EUSERS > > EINPROGRESS > > > > None are perfect but I'm leaning toward EINPROGRESS. > > I really, really dislike that idea. The whole point of not forcing > evictions is to make it clear - no this inode is "busy" you can't > do that. A reasonably smart application can try to evict itself. > > But returning an error and doing a lazy change anyway is straight from > the playbook for arcane and confusing API designs. Agreed. That's why I wrote that applications can set FS_XFLAG_DAX and then query statx for STATX_ATTR_DAX to find out if it actually took effect, and that if applications require it immediately they can either create a file in a FS_XFLAG_DAX directory, or the admin can mount with dax=always. No magic return values required or desired anywhere. I don't know what "try to evict the inode" magic means, but I'm fairly sure I don't want to. ;) --D
