Re: desired autofs semantics (was: Announcing Trapfs...)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam J. Richter wrote:
> Mike Waychison wrote:
> 
>>[...] trying to 'expire' data, which is neccesary for
>>autofs-like functionality..
> 
> 
> 	I think it would be useful to have some sort of time stamp in
> either the superblock or the vfsmount to indicate the last time the
> tree was accessed, and then have some way for an auto-unmount program
> run from cron to read these timestamps.
> 
> 	For an autofs application, such a scheme would probably not
> need any additional kernel help with race conditions, because if a
> user accesses the file system between the time umount interrogates and
> the time umount tries to do the unmount, it should still be harmless
> to try the umount, regardless of whether the umount succeeds or fails.
> Since, if the umount succeeds but the directory has just come back
> into use, the directory will get automounted again.
> 

Please see http://lwn.net/Articles/65193/ "Towards a modern autofs"
section 5.4 -- "Expiry" for why this doesn't work.

> 
> 
>>Also wrt autofs functionality, this lacks the ability to 'trap' on the
>>root directory of a filesystem and the ability to 'ghost' directories
>>and only perform actions when they are walked into. See the autofsng
>>tree at http://autofsng.bkbits.net/linux-2.6-autofsng to see how I do
>>this using ->follow_link traps.
> 
> 
> 	I get file not found when I give my web browser that URL.
> 

That's the http bk url.  The web interface is at:

http://autofsng.bkbits.net:8080/linux-2.6-autofsng

> 	I think I only partly understand what your describing.  I am
> going to guess that the semantics are that if I stat() the mount
> point, I will receive fake information, but that information will
> indicate that this root inode is a *directory*.  If I "cd" to it,
> something might or might not be triggered, but if I do a "getdirents"
> of that root directory, that will trigger some kind of automatic
> remounting.

Yes.  However, you can't reliably perform a mount on ->lookup.  Autofs 4
currently does this, but it makes the assumption that it is you are
walking to change your cwd.  This makes accessing resources using a path
that crosses an non-yet-mounted autofs point not able to 'pivot' 'into
the automounted filesytem before continuing on with path walking.

> 
> 	If that is exactly functionality that you want, then the
> lookup trapping extension for tmpfs probably will not do it for you.
> However, perhaps you could write a really tiny file system that just
> has a root inode that has a follow_link function that calls
> call_fs_helper() and then adjusts nameidata if something has been
> overlayed on its mount point after call_fs_helper has run.  Perhaps it
> might also want to hold a semaphore somewhere to serialize similar
> requests.

Yes, autofsng does this using a the new autofs filesystem with the
'direct' mount option.  Call-outs are handled by the making mount
'request', which are then indexed into a currently active list of
requests and the process with sleep on a completion.
> 
> 	By the way, if you don't mind seeing *symlinks* for nodes that
> are not mounted, you might be able to use the tmpfs lookup trapping
> without any kernel changes.  By having a non-trapping /auto directory
> that contains a symlinks into to the actual trapping tmpfs.

That defeats the entire purpose of autofs.  Automounting used to be
handled by amd-style solutions and it was found that using symlinks to
aid automounting caused too-many headaches, hence the development of autofs.

 - Using symlinks to aid in automounting means you can't use any
relative symlinks within the automounted filesystems..   they won't
resolve to the right place.

- - applications can't reliably use getcwd, cause it is always a
tempoarary/invalid path to any other machine.

- - applications are forced to do path walking in userspace only to be
able to have sensible chdir("..")/open("foo/../bar") support.

> 
> 	If you wanted to be a bit fancier, the user level helper
> script to remove the appropriate symlink from /auto, create a
> directory in /auto, and put a symlink back in the tmpfs directory
> to /auto so that the access that triggered the user level helper will
> succeed return.
> 
> 	You could set it up like this:
> 
> % mount -t tmpfs x /public
> % mount -t tmpfs -o helper='/sbin/my-autofs-helper /detector /public' x /detector
> % ln -s /detector/{host1,host2,host3,host4} /public/
> 
> 	...where /sbin/my-autofs-helper would look something like this:
> 
> #!/bin/sh
> echo "$0 $*" > /dev/pts/1
> host=$4
> detector=$1/$host
> public=$2/$host
> # $3 is "LOOKUP"
> rm -f $public
> ssln $public $detector

what is ssln?

> mkdir $public
> mount -t nfs $host:/ $public
> 
> 	I tried this configuration, modified to mount new tmpfs
> partitions instead of using nfs.  I noticed some drawbacks to this use
> of lookup trapping that you probably don't want.  If you do "ls -lF
> /auto", two things will happen which are probably not ideally what you
> want from a user interface standpoint:
> 
> 	1. The "ls -lF /auto"  will trigger mounting of all of the
> 	   subtrees, because "ls -F" will stat the destination of
> 	   each symlink to decide if it should put a trailing "/"
> 	   on the name.
> 
> 	2. The first time you do "ls -lF", you will see a list of symlinks
> 	   that point to directories, but, attempts after that (now that
> 	   all those links have been mounted) will give you a list of
> 	   directories.
> 
> 	Neither of these behaviors is incorrect based on what the
> directory lookup traps do, but it's probably not what you want if you
> are trying to set up a finite predefined list of automatic points,
> that the user is supposed to be able to interrogate without triggering
> a mount.
> 
> 
> [...]
> 
>>>	3. Until the trapfs helper exits, it is impossible to
>>>control-C out of the access that invoked the helper.  This is a
>>>deficiency of the synchronous call_usermodehelper interface.  Every
>>>kernel facility that uses call_usermodhelper has his problem.  There
>>>are a number of ways to fix synchronous call_usermodehelper, and I
>>>surely expect trapfs to use whatever solution is implemented.
>>>
> 
> 
>>Autofs NG also has this issue. I'm still considering what it would take
>>to push this call into a schedule_work invocation. I don't think a
>>call_usermodehelper_interruptible is what is needed.
> 
> 
> 	Why not?
> 

So, I'm trying to think of the semantics.  If you need to call
call_usermodehelper synchronously, it's probably because you are waiting
for userspace to do something. This would imply that you really do want
to know when userspace is done its thing, in which case you need some
form of notification.  In the current synchronous call scheme, the
notificifation is the return of the call.  Upon this notification, you
complete the transaction somehow, otherwise you could have called
asynchronously.

By introducing an interruptible version of the synchronous call, you are
now forced to handle this 'notification' some other way, likely by
adding some sort of notification api.  You might as well be calling
asynchronously then and using some other primitive for sleeping while
you wait.  A completion works well for the case that you can potentially
have many waiters as it has well defined ownership.

wait_for_completion_interruptible flew by on lkml about two weeks ago,
and is potentially what we really want.

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFBi7bZdQs4kOxk3/MRAt4BAJ0brunjrLob685qNIL7VDGNgw5RcwCY9GgF
qf5i/tjRljsPasUclL0A/A==
=rG/9
-----END PGP SIGNATURE-----