On Thu, 9 Dec 2021 at 22:03, Richard Weinberger <richard@xxxxxx> wrote: > > I see. That way we could get rid of file handle wrapping but loose the > NFS clinet inode cache on the re-exporting server, I think. As an avid user of re-exporting over the WAN, we do like to be able to selectively cache as much of the metadata lookups as possible (actimeo=3600, vfs_cache_pressure=1). I'm not sure if losing the re-export server's client inode cache would effect that ability? And on the subject of the "proxy" server and a server per export; if like us, you have 30 servers or mountpoints to re-export but you might only actively use 5-10 of those at any one time, so it is more resource efficient (CPU, RAM, fscache storage) to use a single re-export server for more than one mountpoint re-export. But in the proxy case, maybe the same thing could be achieved with a containerised knfsd with all the proxy servers running on the same server? I'm not sure if you could have shared storage and have multiple fs-cache/cachefilesd in containers though. Either way, I'm interested to see what you come up with. Always happy to test new variations on re-exporting. Daire
