Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix

["William H. Taber" <wtaber@us.ibm.com>]

Ian Kent wrote:

>>I am a little unclear about this.  Which directory are you talking about?  The
>>mount-over directory or the directory being mounted?  My picture of things
>>(and I haven't verified this by doing anything mundane like reading the code)
>>is that There is a directory (such as /net ) which is of type autofs and as
>>needed new directories of type autofs are created under it for the various
>>hosts/filenames.  Over these subdirectories (the mount-over directories) get
>>mounted the remote filesystems, usually of type NFS.  Is this a correct
>>understanding?
> 
> 
> Yep. That's an indirect mount.

OK.  Got it.
> 
> The directories I'm refering to are the ones created inside the autofs 
> mount point /net or other autofs mount point. Creating the directories 
> makes them browsable without necessarily mounting them (as long as the 
> module knows when to trigger a mount request). This lazyness is what 
> causes all the fus.
> 
> 
>>>Case 2 needs special attention. To achieve this I would need to have two
>>>types of unhashed dentry, valid and invalid (perhaps because of a ENOENT
>>>return from the daemon on mount).
>>>
>>
>>If my understanding above is correct, I don't think you need to hide the
>>dentry for the autofs mount-over directory.  If there is an active mount, then
>>the dentries d_mounted flag will be set and the normal mountpoint traversal
>>will work.  If nothing is mounted here then the autofs mount-over directory
>>lookup functions will be called.  This is where the actual mount request gets
>>triggered.  The dentry created here should not be added to the dentry cache
>>until the dentry is actually ready to use.  It has to be kept in a way that
>>can be found by subsequent calls to lookup in case there are multiple requests
>>for it. The trick is that the first lookup to succeed has to be the one for
>>the mount request.  But once it is on the dentry hash chain, revalidate has to
>>be careful because if the revalidate fails then the dentry will be
>>invalidated.  And if revalidate succeeds then everything needs to be setup so
>>that folow_down will work.  Hmm.  I will have to think about this some more.
> 
> 
> That was how things used to work but late mounting is what's needed to 
> provide the function expected of an automounter when people start using 
> this in an enterprise environment. Basically autofs tells lies until it's 
> forced to tell the truth.
> 
> Point is people expect to be able to see the mount points without causing 
> them to mount until they actually try and access something inside the 
> mount.
> 
> Hence "browseable".
> 
OK.  This is a whole other kettle of fish.
This means that readdir lies and reports about the existance of 
directories but doesn't mount them until someone is actually foolish 
enough to include them in a pathname.  That's the problem.  Too many 
fools. :^)

And thanks for the pointer to the paper.

Will