From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Waychison Subject: Re: desired autofs semantics (was: Announcing Trapfs...) Date: Fri, 05 Nov 2004 12:22:33 -0500 Message-ID: <418BB6D9.70505@sun.com> References: <200411050803.iA583en24375@adam.yggdrasil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Cc: linux-fsdevel@vger.kernel.org, thockin@hockin.org Return-path: Received: from nwkea-mail-2.sun.com ([192.18.42.14]:1205 "EHLO nwkea-mail-2.sun.com") by vger.kernel.org with ESMTP id S262717AbUKERXF (ORCPT ); Fri, 5 Nov 2004 12:23:05 -0500 Received: from phys-mpk-2 ([129.146.11.82]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iA5HN47s021064 for ; Fri, 5 Nov 2004 09:23:05 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I6P00201UVTVM@mpk-mail1.sfbay.sun.com> (original mail from Michael.Waychison@Sun.COM) for linux-fsdevel@vger.kernel.org; Fri, 05 Nov 2004 09:23:04 -0800 (PST) In-reply-to: <200411050803.iA583en24375@adam.yggdrasil.com> To: "Adam J. Richter" Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org -----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-----