Date: Wed, 25 Oct 2000 09:44:25 -0700 (PDT) From: Jim Pirzyk <Jim.Pirzyk@disney.com> To: tlambert@primenet.com Cc: freebsd-hackers@FreeBSD.ORG, Jim.Pirzyk@disney.com Subject: Re: AutoFS on FreeBSD Message-ID: <200010251644.JAA04278@snoopy.fan.fa.disney.com>
next in thread | raw e-mail | index | archive | help
On Wed, 25 Oct 2000, Terry Lambert wrote: > > 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. Yes the attempt to mount the dir should be delayed until it is needed. But if the user cached the dir name with the results of a pwd/cwd, the it still would have the back door name of /tmp_mnt/... > > 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. But fchdir needs a int fd argument (a open file handle) that was used by open(2), so if you close the fd, then the fchdir will fail and not work correctly. There is no way that I can see to use fchdir with out open(2). And we want the mount to expire. Modifiy at is just an ugly workaround for the problem in the first place. In addition to fixing 'at' you would have to fix 'csh' & 'tcsh'(ksh does not have the problem). > > 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. But since the users see the sym link name, it is not the same. The user cd's to /home/$LOGIN and when they do a pwd (in csh), they see /tmp_mnt/home/$LOGIN and say, "hey that is now where I cd'ed to, what is going on here". We move data around every week or so, and so we use symbolic names for our paths, like /data/ada18, but this week pwd returns /tmp_mnt/aj/export/bay_l1g1, but next week it could return /tmp_mnt/oilspot/january_b1g1 and we do NOT want our users to use those names at all. (We move data around so often because of defragging XFS file sysems or now we are in the process of upgrading XFS v1 to XFS v2 file systems. With around 10T of space, we do about 200 - 400GB over a weekend. Ther is a design bug in XFS v1 that if you have a long file name with most of the first characters the same, and then mount that filesystem over NFS, you will not see the second file. This is because of collisions in the hash table in the XFS directory. Yuck). > > 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? No, I did not. This is very interesting. Have any pointers to where I would start looking. > If the problem is the "at" problem, I'd suggest that a simple > change to the problem software would also fix the problem. Nope, more than just at, it is the use of sym links in the mounts. Now I do see that amd had some sort of autofs mount type instead of nfs. That may work, but I do not know anything about it. > At worst, I'd suggest use of static maps, distributed via NIS, > to resolve the problem. Huhhh? We do use NIS to distribute our maps but that does not solve our problem. At one studio, we have to parallel maps, one for automount (auto.home and etc) and one for amd (amd.home) and the amd maps are auto generated from the automount maps. This works ok but does limit what options we can use in the automount maps (since in automounter you can define variables with -DIF=-atm on the command line). I have not been able to find out how to define my own variables in amd to use in my maps without recompiling. > 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). But the need to fix the caching the path information is in every program. Seems better to fix it in one place than in X where X is very large. One may not even be able to fix it everywhere, like in third party apps. (unless one fixes getwd()). > 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? The support of "standard" automount maps would be a big plus but the sym link issue is the major problem. It could be such a potental problem for us that it could jepordize the use of FreeBSD as a viable platform. > 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... I hope I have cleared up what I am after ( a better user experience ). Thanks - JimP -- --- @(#) $Id: dot.signature,v 1.9 2000/07/10 16:43:05 pirzyk Exp $ __o Jim.Pirzyk@disney.com ------------------------------------- _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) 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?200010251644.JAA04278>