Re: [autofs] [RFC] Towards a Modern Autofs

[Mike Waychison]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5E7A436193FFFE5FA916DA2B
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

raven@xxxxxxxxxx wrote:

>On Mon, 12 Jan 2004, Mike Waychison wrote:
>
>  
>
>>>Transparency of an autofs filesystem (as I'm calling it) is the situation
>>>where, given a map
>>>
>>>/usr	/man1	server:/usr/man1
>>>	/man2	server:/usr/man2
>>>
>>>where the filesystem /usr contains, say a directory lib, that needs to be
>>>available while also seeing the automounted directories.
>>>
>>> 
>>>
>>>      
>>>
>>I see.  This requires direct mount triggers to do properly.  Trying to 
>>do it with some sort of passthrough to the underlying filesystem is a 
>>nightmare waiting to happen..
>>
>>    
>>
>
>So what are we saying here?
>
>We install triggers at /usr/man1 and /usr/man2.
>Then suppose the map had a nobrowse option.
>  
>
This is a direct map.  The browse / nobrowse options do not apply to 
direct maps.

>Does the trigger also take care of hiding man1 and man2?
>
>  
>
No.  man1 and man2 appear as directories to anyone doing an lstat on 
them.  Traversing *into* them will cause filesystems to be mounted on 
them.  This appears to be similar to browsing of an indirect map at 
first, however it is a different beast.  With indirect maps, we are 
given the right to cover up /usr to help us detects stats and traversals 
into its sub-directories.  With direct entries, we don't have these 
leisure.  Everything in /usr most be accessible at all times. 

Your need for 'transparency' comes from the fact that you convert direct 
maps into indirect maps, which require the covering of /usr.

>Is there some definition of these triggers?
>
>  
>
This question is up in the air. 

I propose using a magic filesystem, whose root dentry has a follow_link 
callback defined.  When somebody walks into the filesystem, the 
follow_link is called, which does the mount onto a different dentry, and 
then forwards the original caller to the new vfsmount/dentry pair. 

HPA and Viro believe this is better done in the VFS layer directly by 
using special vfsmounts without super_blocks.  The path walking code 
would be modified to know of these 'traps' or 'triggers' natively.

Which solution is best is left as an exercise.

-- 
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison@xxxxxxx
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 


--------------enig5E7A436193FFFE5FA916DA2B
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFABD0cdQs4kOxk3/MRAl02AJ9DeLf53/wgbXORk2P/11UkCKKRHgCfYQ4j
Jsl0hzwGpzEN0Cyy26d8+oc=
=6X1I
-----END PGP SIGNATURE-----

--------------enig5E7A436193FFFE5FA916DA2B--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/