Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!pacbell.com!ames!haven!mimsy!mojo!lidl
From: lidl@eng.umd.edu (Kurt J. Lidl)
Newsgroups: comp.unix.admin
Subject: Re: comp.unix.admin.large
Message-ID: <1990Dec18.231625.26437@eng.umd.edu>
Date: 18 Dec 90 23:16:25 GMT
References: <609@synopsys.COM>
Sender: news@eng.umd.edu (C-News)
Organization: Merriversity of Uniland, College Purgatory
Lines: 108

In article <609@synopsys.COM> arnold@mango.synopsys.com (Arnold de Leon) writes:
>I am in the process of redesigning the way provide /usr/local/{bin,etc,lib,man}
>
>Here is what I have in mind
>
>        o automount /usr/local

Difficult to do.  But not impossible.  If you are talking about a system
that understands dynamically linked libraries, and any of those
libraries live in /usr/local/lib, then you have a real headache in
store.  (I've been thinking about this a lot.)

You need (at least with Sun's dynamically linked libraries) to issue
a 'ldconfig' command to get things to work properly.  This is done
at system startup.  If you are continually mounting and unmounting
the /usr/local/lib filesystem, then you need to be aware of this
little snafu.

>        o any 'package' containing more than one binary would be
>          installed in it's own directory.
>                Example:  perl
>                        /usr/local/perl/{bin,lib,man} would be created.
>                        The contents of /usr/local/perl/{bin,lib,man}
>                        would be symlinked to /usr/local/{bin,lib,man}
>                        as needed.

Sounds pretty good.  We went a step further and made /usr/local/bin
*ALL* sym-links.  We made a /usr/local/misc for the one and two program
pakages.  This has the nice effect of telling us what the binaries
in /usr/local/bin are really from -- otherwise it is extremely
difficult to pinpoint the source of commands... This is a bigger
benefit than you think of immediatedly when it comes time to
upgrade an OS...

>        o a side-effect is /usr/local/bin will be mostly symbolic links

Make sure that you make the sym-links relative to /usr/local/bin
itself.  This way, you can mount your current /usr/local as /old/local
and still have things going to the correct place.  Very handy as a
crutch when upgrading operating systems.

>Motivation:
>        + allow packages to be distributed on different files servers
>          while allowing a consistent name space.
                          ^^^^^^^^^^^^^^^^^^^^^^^

Amen to this effort.  We are attempting a similar thing on 5 different
hardware/OS platforms.

>        + automounting will allow 'critical' packages to be replicated,
>          also it would be easy to move packages

See cautions above regarding dynamically linked libraries.  Also,
if you have any daemons that you run, move them off the automounted
filesystems.  Otherwise your automounting will screw the daemons
on a regular basis.

>        + easier to update and deinstall software.  All the binaries,
>          libaries are in one place.  Useful with large installations
>          with multiple sys admins.

Right.  I would advocate the use of relative sym-links as above.

>        + responsibility for packages can be more easily delagated to
>          others.

Right.  However, some sprawling packages rely on too many things.
A good example of this is TeX.  You have got {la,Sli,AmS}TeX, their
font families, screen previewers for sunview, screen previewers for X11,
etc, etc...

>        + easier to make a binary distribution for others (in my case,
>          remote sales offices).

Very much so.  One of the reasons that we are doing this is for
supporting external groups.

>        - LOTS of symbolic links, possible performance hit

Tradeoffs are everywhere.  I think that this is not too bad.

>        - initial command generate automount mount request, another possible
>          performance
>
>	? possible automount mount storm on hashing of paths?

If the /usr/local/bin is autmounted, then there will be one automount
request for the initial /usr/local/bin automount.  If you have say,
/usr/local/perl and /usr/local/bin in your directory, then you will
start to encounter the an automount mount request storm.  Keep in mind
that many rpc.mountd/mountd implementations do the *wrong* thing with
processing a large queue of incoming mount requests.  The SunOS versions
prior to that in 4.1.0 process the queue in a strange manner.  Performance
suffers for it.

>        What do you think of the possible performance problem?  Is there
>one?  Is it significant enough to worry about or is it small enough
>to ignore.  Is the performance problem heavily tied to into usage
>patterns?  If so what are the really bad cases?

For this version of our /usr/local project, we are simply mounting /usr,
/local, and /usr/local on startup.  Home directories, mail spools,
and bought application software automount on demand.  Automounting of
/usr/local and so forth will come in release 2.0, next summer. (hopefully)

--
/* Kurt J. Lidl (lidl@eng.umd.edu) | Unix is the answer, but only if you */
/* UUCP: uunet!eng.umd.edu!lidl    | phrase the question very carefully. */