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. > 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? 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. > 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. > 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. Thanks, Miklos
