Date: Wed, 25 Oct 2000 21:30:03 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: Jim.Pirzyk@disney.com (Jim Pirzyk) Cc: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG, Jim.Pirzyk@disney.com Subject: Re: AutoFS on FreeBSD Message-ID: <200010252130.OAA04864@usr01.primenet.com> In-Reply-To: <200010251644.JAA04278@snoopy.fan.fa.disney.com> from "Jim Pirzyk" at Oct 25, 2000 09:44:25 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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/... [ ... symlink expansion ... ] The easiest fix is to fix symlinks to actually use reference inodes to refer to the real inodes, and not expand inline unless referenced explicitly through "readlink". The same approach would establish explicit parents for hardlinks. The pain here is that following a symlink loses your parent path, when it shouldn't. I still think users who are surprised at this shouldn't be looking behind the curtain, if they are not sure they will like what they find there, but am sympathetic to administrator worries. The problem boils down to knowing the parent pointer of a directory being pointed to; on a mount, that's explicit, since there is a 1:1 relationship, but on a symlink, there is no 1:1 enforcement. In the speed argument case, the argument against symlinks is destroyed if they are replaced by mounts, in any case, since comparisons against the device/inode number of all mounted FSs is vastly more expensive, overall, than simply expanding a symlink. I think if the cwd approach is used, you'll see that the mount will stay busy, so long as there are users sitting on a current directory, since a current directory reference is identical to an open file handle. The only exception is cd-cache-go_away- come-back, which is still a problem. The way my ISP handled this is to mount user's home directories onto /user/t (for /usr/t/terry, etc.), and let that be the explicit automount point, so that the directory never changes out from under the user. The actual FS mounted is never really exposed to the user's view, unless they do a "df" or a "mount" (the latter is restricted, while the former refuses to show NFS volumes); in any case, it would not naturally show the server in a getcwd result. Another option is to mount several FS instances using the automounter as one instance per FS. This would result in the mount point also appearing to be static, and can be done with creative amd maps (David Wolfskill did this for the engineering department a Whistle/IBM). Then there's always doing the dirty deed. On the plus side, you can use the direct approach that deadlocked them, since in BSD, the directories being covered don't need to exist as real things. The BSD VFS interface also allows you to cause a VFS layer to "eat" path components, so you could hide your symlink issue, and still use symlinks, if you wanted to do it that way. > > 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. You need to look in the -announce or -fs list archives; I believe the author of the note was Erez, Marius, or Karsten. Basically, another Eastern block maniac, of the type that brought us VGA displays built on ASCII art so that we can watch mpeg videos on Televideo 925s or MDA cards, has hacked up code that mmap's Linux FS modules into a user space process, and then satisfies their dependencies, allowing them to run via an NFS loopback. I remember it because it was so insane an idea, but it apparently worked well enough to announce; I believe that it was released around the same time as 3.4-STABLE. Unfortunately, the list archives are a bit spotty. I think the Erez is the primary investigator on FiST (it's his PhD thesis, if I remember correctly), and it may already implement AutoFS support. FiST runs under both FreeBSD and Linux, so it is an alternative, common ABI. > I hope I have cleared up what I am after ( a better user experience ). Understood; just looking for alternatives that don't have you doing a lot of coding yourself or trying to get someone else to do a lot of coding. You best bet, if you pursue this further, is to contact the freebsd-fs list instead of the freebsd-hackers list, since the people who hack FS code are all there, and not all here (as opposed to the people on hackers, who are "not all there" 8-)). 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?200010252130.OAA04864>