Re: A puzzling timing issue with automounted home directories

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

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

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!

[Index of Archives]     [Linux Filesystem Development]     [Linux Ext4]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux