On 10/8/20 9:30 AM, Ian Kent wrote:
All that attribute checking the NFS kernel client does is meant to
identify when a path component has changed, there's a lot of it.
Possibly what's happening is the VFS isn't calling ->d_revalidate(),
possibly during the lockless part of the path walk, because it's the
parent, not the last component of the path, and it doesn't appear its
changed based on what the VFS can check in that mode (so called
rcu-walk).
If that is the case it will likely be rather difficult for the VFS to
deal with, so essentially I suspect it's an NFS problem.
Someone contacted me off list about this and suggested it was a problem
with negative VFS dentry caching, and this proved to be correct. If I
set lookupcache=pos for the autofs mount; e.g. use this /etc/auto.home:
* -tcp,vers=4.2,lookupcache=pos helios.biosci.utexas.edu:/home/&
the problem goes away and the new home directory is found with no sleep
necessary. Of course not doing the negative caching (i.e. not caching
things which aren't found) has performance consequences for software
(like most of the stuff we use) that searches paths for dynamically
loadable libraries.
So, as you suggest, it doesn't look like there's a good solution to
this. New users are just going to have to wait 70 seconds the first
time they log in, since this is pretty obviously the lesser of 2 evils.
It's nevertheless nice to understand what's going on.
Thanks for your help with this!
