On Fri, Apr 12, 2024 at 11:17 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Fri, 12 Apr 2024 at 09:12, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > Not fh value per-se but a backing id, allocated and attached to fuse inode > > on LOOKUP reply, which sticks with this inode until evict/forget. > > OPEN replies on this sort of inode would have to either explicitly state > > FOPEN_PASSTHROUGH or we can allow the kernel to imply passthrough > > mode open in this case. Not sure. > > Hmm, maybe allowing a zero backing_id to mean "use current backing > inode" would be sane. And if there's no current backing for the > inode, and a zero backing ID is given then it would just return > -ENOENT or something. > > I wouldn't change anything else, so FOPEN_PASSTHROUGH would still need > to be given and all the other states would work. The only difference > would be that LOOKUP would allow setting up a backing path (need to > think about naming, because all these backing somethings are a bit > confusing). > > Thoughts? Sounds good, except returning ENOENT to user for open with zero backing id is confusing, so I think it has to be EIO like all the other illegal passthrough open replies. Thanks, Amir.
