On Mon, Sep 07, 2020 at 06:31:00PM +0100, Daire Byrne wrote: > 1) The kernel can drop entries out of the NFS client inode cache (under > memory cache churn) when those filehandles are still being used by the > knfsd's remote clients resulting in sporadic and random stale filehandles. > This seems to be mostly for directories from what I've seen. Does the NFS > client not know that knfsd is still using those files/dirs? The workaround is > to never drop inode & dentry caches on the re-export servers > (vfs_cache_pressure=1). This also helps to ensure that we actually make the > most of our actimeo=3600,nocto mount options for the full specified time.
I thought reexport worked by embedding the original server's filehandles in the filehandles given out by the reexporting server. So, even if nothing's cached, when the reexporting server gets a filehandle, it should be able to extract the original filehandle from it and use that. I wonder why that's not working? > 4) With an NFSv4 re-export, lots of open/close requests (hundreds per > second) quickly eat up the CPU on the re-export server and perf top > shows we are mostly in native_queued_spin_lock_slowpath. Any statistics on who's calling that function? > Does NFSv4 > also need an open file cache like that added to NFSv3? Our workaround > is to either fix the thing doing lots of repeated open/closes or use > NFSv3 instead. NFSv4 uses the same file cache. It might be the file cache that's at fault, in fact.... --b. -- Linux-cachefs mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-cachefs
