Date: Sat, 4 Jul 1998 21:09:42 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: witr@rwwa.com (Robert Withrow) Cc: hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <199807042109.OAA02700@usr02.primenet.com> In-Reply-To: <199807031307.JAA02925@spooky.rwwa.com> from "Robert Withrow" at Jul 3, 98 09:07:21 am
next in thread | previous in thread | raw e-mail | index | archive | help
> :- Eventually, we concluded that the fact that a symlink can change > :- because of an 'external' influence was a bad idea. > > More or less, so did I. As you point it it seems to be an > idea that doesn't scale well. > > In our environment of > 1000 computers and approx 100 automounted > filesystems, I'd worry that the const of management of using this feature > would exceed the benefit. One problem with a non-hierachical approach is that two of the most interesting applications are per process, not per system. This fits poorly into the "put it in sysconfig" model. > Note that AMD solves a similiar problem in different way. For > example, /usr/global/bin gets directed to the correct filesystem > based on the architecture/os. One issue with amd (which is only partially resolvable using the symlink generation on the mounted fs instead of loopback) is that loopback mounts via NFS are poison. It is rather easy to hang every process using the loopback with a nice starvation deadlock when using it for programs for which the loopback is a swap store. Pretty much every time a local application server bounces (from which I run netscape and fvwm95 locally) I end up having to reboot my FreeBSD box because it believe the NFS handles are "stale", and does not properly recover operations in progress at the time of the bounce. This was a real problem, when the machine in question had hardware stability problems recently. I felt like my FreeBSD box had been turned into a (Gack!) PC. FS architecture politics aside, the use of the existing NFS client code for critical functions like locating your real /usr/lib would be a *very* bad move. It's a resolv*able* problem, but it is not a resolv*ed* problem. > Perhaps a *limited* form of this feature (for example, not involving a > users ENV) might be useful. I don't think that our internal support > people would like a sitation where who filesystem subtrees disappear > or get misdirected do to a hapless user accidentally clobbering a > environment variable named, say, "OS". Per previous discussion: this can't happen, if it's implemented correctly. The particular environment variable in question on the a.out issue would be (re)set in the execve(2), and apply to the process about to run, in any case. It's children would derive the same variable. A program could screw itself, without the namespace escape being implemented, but it couldn't screw another program, even subprocesses. 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?199807042109.OAA02700>