Re: [RFC] Towards a Modern Autofs

[Mike Waychison <Michael.Waychison@Sun.COM>]

[-- Attachment #1.1: Type: text/plain, Size: 5300 bytes --]

Ian Kent wrote:

>On Thu, 8 Jan 2004, Mike Waychison wrote:
>
>  
>
>>The direct map 'triggers' will be taken care of by another filesystem
>>with a magic root directory that will catch traversals using some
>>follow_link magic.   I wrote a prototype for this last summer, but
>>haven't released it as the userspace stuff completely does not fit in
>>with the existing daemon that was out at the time do the the mess of
>>glue that was pgids, pipes and processes.   It worked in the simple
>>case, but it didn't extend to being able to direct mount an indirect
>>map, nor was it able to do the lazy mounting in multimounts as I had
>>desired.
>>    
>>
>
>Is this the stuf that Al Viro is working on?
>
>  
>
Al is proposing doing the same thing directly in the VFS instead of 
using a magic filesystem as I've described in the document.  

> Indeed, I
>haven't solved my requirement of a transparent autofs filesystem aka.
>Solaris automounter again. A difficult problem that will require
>considerable effort.
>
>  
>
What do you mean by this?  Something that doesn't show up in 
/proc/mounts?  I don't see this as much of an issue..  On any decently 
large machine, there are so many entries anyway that /etc/mtab and 
/proc/mounts become humanly unparseable anyhow.

>>>>This is the subtle difference between direct and indirect maps.   The
>>>>direct map keys are absolute paths, not path components.  We are
>>>>implementing direct mounts as individual filesystems that will trap on
>>>>traversal into their base directory.  This filesystem has no idea where
>>>>it is located as far as the user is concerned.  We need to tell the
>>>>filesystem directly so that the usermode helper can look it up.
>>>>Conversely, the indirect map uses the sub-directory name as a mapkey.
>>>>
>>>>
>>>>        
>>>>
>>>I'm not sure what you are saying here. Does this mean there is a mount for
>>>every direct mount (this might be what you call a trigger)?
>>>
>>>
>>>
>>>      
>>>
>>Yes, it is its own filesystem (type autofs).  This is needed because we
>>need to overlay direct triggers within NFS filesystems for multimounts.
>>    
>>
>
>Ahh. I see, you are talking about the cross filesystem problem. I haven't
>solved that in what I have done either. Fortuneately I still get a good
>hit rate in satisfying peoples' needs as in practice many people don't use
>full automounter functionality.
>
>  
>
Yup.  But still, one of the nice things about a full automounter 
solution is accessing a netapp with hundreds of exports through /net in 
a reasonably fast way.

>>??  Really?  I find that hard to believe.  I thought Solaris shared it's
>>automounter with HPUX and AIX.  I may be wrong though.
>>    
>>
>
>Old versions perhaps. AIX 4.x was the last I used. It was definately like
>that then. 500+ automounts tends to cluter the mount display a bit.
>
>  
>
Could be.  Either way, on a system with a thousand NFS shares 
automounted, I'm not really concerned about what the mounttable looks 
like.  It won't be human parseable anyway.

>>>Mmm. The vfsmount_lock is available to modules in 2.6. At least it was in
>>>test11. I'm sure I compiled the module under 2.6 as well???
>>>
>>>I thought that, taking the dcache_lock was the correct thing to do when
>>>traversing a dentry list?
>>>
>>>
>>>
>>>      
>>>
>>Walking dentrys still takes the dcache_lock, however walking vfsmounts
>>takes the vfsmount_lock.  dcache_lock is no longer used for fast path
>>walking either (to the best of my understanding).
>>
>>find . -name '*.[ch]' -not -path '*SCCS*' | xargs grep vfsmount_lock |
>>grep EXPORT
>>    
>>
>
>Strange. How does the module compile I wonder? How does it load without
>unresolved symbols? Another little mystery to work on.
>
>  
>
No, you're module doesn't use vfsmount_lock.  At least the module in 
autofs4-2.4-module-20031201.tar.gz doesn't.

>>The raciness comes from the fact that we now support the lazy-mounting
>>of multimount offsets using embedded direct mounts.  Autofs4 mounts all
>>(or as much as it can) from the multimount all together, and unmounts it
>>all on expiry.
>>    
>>
>
>But 4.1 does lazy mount for several maps. Mounts that are triggered
>during the umount step of the expire are put on a wait queue along with
>the task requesting the umount. I think autofs always worked that way.
>
>  
>
This isn't lazy mounting per se.  If you are talking about autofs4's use 
of AUTOFS_INF_EXPIRING, it's there to prevent somebody from walking into 
a multimount while it is expiring. 

>>>Hang on. From the discussion my impression of a lazy mount is that it is
>>>not actually mounted!
>>>
>>>
>>>
>>>      
>>>
>>Lazy _un_mounts as opposed to lazy mounts. Lazy unmounts are described
>>in umount(8):
>>    
>>
>
>But will this leave the filesystem in a consistent state and allow further
>mount activity on that mount point?
>  
>
The underlying autofs filesystem?  Sure.


-- 
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison@Sun.COM
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me, 
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 


[-- Attachment #1.2: Type: application/pgp-signature, Size: 251 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs