On Tue, Oct 31, 2023 at 5:01 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Tue, 31 Oct 2023 at 13:31, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > Current patch set does not implement "backing inode" for FUSE inode, > > What prevents us from storing a fuse_backing reference in fuse_inode > while the file(s) are open? > > AFAICS it just needs a counter in fuse_inode to account the number of > open instances. > The current patches do not enforce that all fuse_file of the same fuse_inode passthrough to the same backing_file (or same backing inode). I agree that functionally, we could enforce that, and it may be good for "backing inode" mapping on lookup going forward The problem is that at the time of FUSE_DEV_IOC_BACKING_OPEN, we do not know which fuse_inode is going to be associated with the fuse_backing object. v13 patches had a mode that pass nodeid with the fuse_backing_map request (inode bound mode) and refcount the fuse_backing object from the fuse_inode (with no backing idr) at the time of the ioctl and then -EBUSY could be returned for a conflicting backing map request. The problem with that API was with CREATE of a new nodeid, where the FUSE_DEV_IOC_BACKING_OPEN ioctl happens before fuse knows about the new nodeid. In that case, we would be able to "attach" the fuse_backing object to fuse_inode on CREATE response. If we end up with a backing map conflict at this point, we can return -EBUSY error to the user and forget the inode, but the server would have no easy feedback on its mistake. Also, -EBUSY to user would be confusing if user did not request O_EXCL. Do you consider the described "atomic_open conflict" case an API problem? It is true that with v14 patches that do not enforce backing inode conflicts, the attribute coherency model that I proposed may result in attribute cache thrashing if the backing inode of a fuse inode is ambiguous. Do you have an idea how to handle this case elegantly? Thanks, Amir.
