Date: Wed, 25 Oct 2000 09:47:50 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: Jim.Pirzyk@disney.com (Jim Pirzyk) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: AutoFS on FreeBSD Message-ID: <200010250947.CAA18929@usr02.primenet.com> In-Reply-To: <00102417462400.00469@snoopy.fan.fa.disney.com> from "Jim Pirzyk" at Oct 24, 2000 05:24:06 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> I was wondering if there is anyone working on AutoFS for FreeBSD. We > currently have 4 studios with around 1000 unix systems of all kinds. > Currently there are only 2 OSes that do not have autofs, FreeBSD and one > that is known for its number crunching capabilties (and those are being > phased out of production). Amd will not meet our needs because of the > use of sym links. This is why AutoFS was written in the first place. > I quote the 1993 USENIX paper on AutoFS (check > http://www.usenix.org/publications/library/proceedings/cinci93/full_papers/callaghan.txt > for the full paper). [ ... AutoFS Introduction ... ] [ ... NFS automounter "problems" ... ] > However, if a process invokes the getwd() function to obtain the path > of the current directory while in an automounted filesystem, it will > obtain a "/tmp_mnt/..." path. If this "back door" path is cached and > used sometime later, there is no guarantee that the filesystem will > still be mounted there. I think that the attempt to change to the directory should be delayed until the event. This will cause the use of the forward path, which, if there is a timeout, will reinvoke the automounter, correctly. > A common victim of this behavior is the at command. It uses the pwd > command to record the current directory so that it can be cd'ed to > for subsequent invocation of the script. I think this is a bug in the "at" command. If you want, I can provide patches which implement the behaviour using "open(2)" and "fchdir(2)", instead of recording the "cwd path". Alternately, I can provide patches to make it use the command line path instead, using evaluation of the path not involving "readlink(2)". I would personally prefer the "fchdir(2)" method, since the "open(2)" will keep the mount active, so it isn't allowed to time out. > The symbolic links also confuse users [...] This argument is an attempt to pile on; not a very good one. As long as the software does what it's supposed to do, user's don't have to be able to understand it to make it work. Look how many people drive cars, but don't understand how they operate or program C, with no understanding of the assembly language the compiler will produce as a result. > If no one is using it, how is it looked apon if AutoFS was ported from > Linux (with the GPL and that stuff) or would a complete rewrite be > better? A complete rewrite would be required for the AutoFS to be included in the system by default, if it were found to be generally desired. I think your problem can probably be solved a lot of ways; if the Linux AutoFS is a module, you are aware that you can use Linux FS modules under FreeBSD, right? If the problem is the "at" problem, I'd suggest that a simple change to the problem software would also fix the problem. At worst, I'd suggest use of static maps, distributed via NIS, to resolve the problem. I think that, given the way BSD covers mount points, the other issues that were raised as problems are really no longer problems, on modern systems. The threading is not an issue, and neither is the map change. The performance issues for the link traversal are really trivial (particularly when you consider that the "get current directory" argument means that the symlinks were never getting traversed, other than the very first reference). I think the "in place mapping" failure that they reported in their implementation would never be an issue under BSD. Is this a requirement that you be able to support "standard" AutoFS mount maps, or is there an issue with the automounter where you are actually experiencing a problem which would be resolved by AutoFS and only AutoFS? In any case, you *could* use the Linux AutoFS module with FreeBSD; there is a port which supports Linux FS modules loaded into user space, but without a clarification of why you want/need an AutoFS, I don't think anyone can tell you whether or not that would be an appropriate technology... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010250947.CAA18929>