Re: [RFC] Towards a Modern Autofs

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

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

Ian Kent wrote:

>On Mon, 12 Jan 2004, Mike Waychison wrote:
>
>  
>
>>>And I have another question concerning namespaces.
>>>
>>>Given that there may be several namespaces, each of which may or may not
>>>have a trigger on this dentry, is there some sort of list of triggers?
>>>
>>>How do the triggers know who owns them?
>>>
>>>
>>>
>>>
>>>      
>>>
>>This is the reason I went with using distinct filesystems to perform the
>>triggers.  If we use follow_link logic, we will have a reference to the
>>respective vfsmount.  Dentry's themselves know nothing about the
>>triggers, as the triggers just look like a mounted filesystem.   The
>>vfsmount information has enough information for autofs to call a
>>userspace agent through hotplug and have userspace handle the mount.  In
>>effect, there is no daemon so nobody 'owns' a trigger in the same sense
>>as with autofs3/4.
>>    
>>
>
>I'm not familiar with the follow_link mechanism (no prob. I'll pick it up
>as I go).
>
>Correct me if I'm wrong but, the only thing that I can see that is
>duplicated in cloning a namespace is the root dentry. The rest of the
>dentries on the system remain the same. The increase in complexity to the
>VFS to change this would be prohibitive.
>  
>
No.  Dentries are *never* duplicated.  This goes back to Viro's work on 
allowing a filesystem to be mounted in multiple locations.  See 
http://kt.zork.net/kernel-traffic/kt20000424_64.html#9 .

What is duplicated is the current->namespace tree of vfsmounts.  After 
this is done, current->fs vfsmount members are updated to point to their 
cloned counterparts.

>I see we want the triggers in the vfsmount struct. Is this a good idea?
>The vfsmount struct has always been difficult to get hold of during lookup
>and revalidate for me (someone like to help here).
>
>  
>
If triggers in the vfsmount struct are done, then there will be no need 
to handle lookups or revalidates.  In fact, triggers in the vfsmount 
struct will not help at all for indirect maps.

>
>Also, something needs to be done about mount table noise. Several hundred
>entries is very bad from an administration viewpoint.
>  
>
I don't see what you want here.  If you have hundreds of users logged 
into the same machine, you *will* have hundreds of entries in the 
mount-table.

>Except for the cross namespace issues, which I'm still digesting, I can't
>see why your design can't be done entirely as a filesystem using dentries
>instead of vfsmount, including expirey. Perhaps you could reinterate a few
>of the reasons for this.
>  
>
My proposal uses filesystems for all automount mechanism *except* 
expiry. I see expiry as a VFS service, and strongly believe that this is 
where it belongs.

-- 
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