On Wed, Nov 1, 2023 at 4:42 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Wed, 1 Nov 2023 at 14:23, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > However, I can imagine users wanting to do passthrough for read-only > > fd without doing passthrough for read-write fd, for example, if data is > > never manipulated by the server, but it is inspected on write. > > Okay, that could make sense in a read-mostly use case. But I think > that special case could be enabled with FOPEN_DIRECT_IO since we have > that anyway. I.e. FOPEN_DIRECT_IO would override the per-inode state, > which is what it does now. > > What doesn't make sense is to mix cached I/O with non-cached (direct > or passthrough) I/O. > That can work. > > I have one problem with my in-house server and passthough of readdir. > > readdir passthrough cannot do readdirplus to populate inode cache. > > For readdir of a large, read-mostly directory, cached readdir is preferred > > because of readdirplus. > > For a large, write-often directory, when only readdir is needed, readdir > > passthough is preferred. > > No one size fits all here. > > But in this case the cache part of readdirplus is not useful, only the > prepopulation part. So why cache in that case? > In my use case, most users use cached readdirplus, so cache is important. There is one user (samba case insensitive create) that opts-out of readdirplus. This user gets passthrough readdir without populating cache nor prepopulate inodes, which is important because in that use case (file create) readdir cache always gets invalidated. This user does not contribute to cache populate of other readdirplus users and does not use cache populated by other readdirplus users. > Now using readdirplus for prepopulation might be the right interface, > but it also might make sense to use it _only_ for that and use > passthrough for the actual readdir. > That would make sense if readdirplus request is sent to server in parallel to executing readdir passthrough and readdirplus response does the prepopulation asynchronously. > > I don't mind dropping the last readdir passthrough patch for the first > > version, if you want to take more time to think this over. > > I'd just like to know that there is a path forward to make conditional > > passthrough per fd possible in future versions. > > I think first version should just do regular file passthrough. > OK. > > BTW, the FUSE BPF patches that map a backing inode to > > fuse inode allow fallback to server depending on BPF program result. > > Yep, that also makes sense. What we need to make sure is that cache > and non-cache access are not mixed, because that way lies madness. > Are you also referring to mixing cached and uncached readdir? because that seems fine to me. I will try to add these rules to FOPEN_PASSTHROUGH: - ignore request on backing inode conflict - ignore request if inode is already open in caching mode - make FOPEN_PASSTHROUGH implicit if inode is already open in passthrough *unless* file is open with FOPEN_DIRECT_IO Thanks, Amir.
