On Wed, 1 Nov 2023 at 19:32, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > I see. so if dir has backing inode, we can always > disable FOPEN_CACHE_DIR (as my patch already does) > but instead of alway doing passthrough readdir, we employ the > heuristic whether or not to do readdirplus. > If not doing readdirplus, we can do fuse_passthrough_readdir(). Okay. > In the future, we could do async readdirplus and always call > fuse_passthrough_readdir() if we have backing inode. Yes. > For now, I will just remove the readdir passthough patch. Yes, let try to do the minimal useful thing first. > > Remember that we would actually need to do backing_file_open() > for all existing open files of the inode. I know. > Also, after the server calls FUSE_DEV_IOC_BACKING_CLOSE, > will the fuse_backing object still be referenced from the inode > (as it was in v13)? and then properly closed only on the last file > close on that inode? Yes, those seem the most intuitive semantics. > I am not convinced that this complexity is a must for the first version. > If the server always sets FOPEN_PASSTHROUGH (as I expect many > servers will) this is unneeded complexity. > > It seems a *lot* easier to do what you suggested and ignore > FOPEN_PASSTHROUGH if the server is not being consistent > with the FOPEN_ flags it uses. The problem with ignoring is that we can't change the semantics later. So I think it would be better to enforce consistency such that if there's already an open file, new open files will have to have the same FOPEN_PASSTHROUGH state, and just reject with EIO if not. Thanks, Miklos
