hahn@ames-nas.arpa (03/12/87)
> In fact, /usr is really a misnomer since most users > usually live on a different file system. I belive that /usr stands for "user service routines." -jonathan hahn NASA Ames Research Center hahn@ames-nas.arpa ...!ames!amelia!hahn
rbj@icst-cmr.arpa (03/14/87)
? > In fact, /usr is really a misnomer since most users ? > usually live on a different file system. ? ? I belive that /usr stands for "user service routines." I always thought it was a contraction of `user'. Anyone from TPC care to comment? And of course /etc stands for Extremely Technical Code :-) ? -jonathan hahn ? NASA Ames Research Center ? hahn@ames-nas.arpa ? ...!ames!amelia!hahn (Root Boy) Jim "Just Say Yes" Cottrell <rbj@icst-cmr.arpa> I'm definitely not in Omaha!
henry@utzoo.UUCP (Henry Spencer) (03/17/87)
> > In fact, /usr is really a misnomer since most users > > usually live on a different file system. > > I belive that /usr stands for "user service routines." Unless somebody fibbed to me in the dim distant past, it's this way. If you look at really old Unix papers, like the original CACM paper (not the updated variants of it in places like Unix manuals!), you will find that the original Unix system had a small fixed-head disk and a larger disk of more normal structure. The fixed-head disk was fast -- by the standards of the time -- but really small. It made sense to put the root file system on the fixed-head disk, but this meant that only the most heavily-used system stuff could live there. The big disk was mostly given over to the file system where user files lived, dubbed /usr for obvious reasons. So the overflow from root went under various "users". This is why the default search path hits both /bin and /usr/bin, because only small and often-used stuff could live in /bin. This is why libraries are split between /lib and /usr/lib, because only the very busiest library stuff could go on the root file system. This is why the sources are under /usr/src. This is why an occasional program like sort, which expects its temporary files to be BIG, creates them in /usr/tmp instead of /tmp. (Of course, more recent system variants have often changed things around, so don't nit-pick if yours does things a little differently -- *my* distribution tape came from Bell Labs, not from XYZ Vaporboxes Inc. or Miskatonic U.) And so forth. Nowadays Unix systems seldom share file systems between user and system files, but /usr as a place for system files lives on because of all of those pathnames that would have to be changed. -- "We must choose: the stars or Henry Spencer @ U of Toronto Zoology the dust. Which shall it be?" {allegra,ihnp4,decvax,pyramid}!utzoo!henry
preece%mycroft@gswd-vms.arpa (Scott E. Preece) (03/18/87)
henry Spencer: > This is why an occasional program like sort, which expects its temporary > files to be BIG, creates them in /usr/tmp instead of /tmp. (Of course, > more recent system variants have often changed things around, so don't > nit-pick if yours does things a little differently -- *my* distribution > tape came from Bell Labs, not from XYZ Vaporboxes Inc. or Miskatonic U.) > And so forth. ---------- On the other hand, today many of us run with nice, b-i-g /tmp partitions and with /usr partitions that are basically static and mostly full, rendering that strategy ill advised... -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms
mwm%violet.Berkeley.EDU@BERKE (No one lives forever.) (03/19/87)
>> On the other hand, today many of us run with nice, b-i-g /tmp partitions >> and with /usr partitions that are basically static and mostly full, >> rendering that strategy ill advised... Yes, but if you did that, you took care of lots of non-static things on /usr besides /usr/tmp. The same technic should be used on /usr/tmp. For instance, the following commands on a BSD system work quite nicely (single-user, with /usr mounted): # rm -rf /usr/tmp # ln -s /tmp /usr/tmp I'd be interested in what you did for V the system, if that's what you're running. <mike
karl@haddock.UUCP (Karl Heuer) (03/20/87)
In article <5025@brl-adm.ARPA> preece%mycroft@gswd-vms.arpa (Scott E. Preece) writes: >[Henry Spencer writes:] >> This is why an occasional program like sort, which expects its temporary >> files to be BIG, creates them in /usr/tmp instead of /tmp. > >On the other hand, today many of us run with nice, b-i-g /tmp partitions >and with /usr partitions that are basically static and mostly full, >rendering that strategy ill advised... Which is one reason why I think *all* temp-using programs should honor the TMPDIR envariable. (Automatic if you use the right function in SysV, but I never remember how it's spelled.) A while back I put a /tmp subdirectory in each mounted filesystem, and (until the space situation stabilized) had my .profile set TMPDIR to whichever had the most room. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint T=${TMPDIR:-/tmp}/$$; trap "exec rm -f $T" 0 1 2 3 15
gwyn@brl-smoke.UUCP (03/21/87)
In article <5025@brl-adm.ARPA> preece%mycroft@gswd-vms.arpa (Scott E. Preece) writes: >On the other hand, today many of us run with nice, b-i-g /tmp partitions >and with /usr partitions that are basically static and mostly full, >rendering that strategy ill advised... So make /usr/tmp a symlink to /tmp, or mount a nice empty fast file system as /usr/tmp. It is essential that /tmp not be used for lots of large files; if /tmp runs out of space, numerous essential system utilities malfunction. (Whether they should break so easily is a separate issue.) The worst offenders (outside the 4BSD world) seem to be some text editors.
chris@nrcvax.UUCP (Chris Grevstad) (03/22/87)
mwm%violet.Berkeley.EDU@BERKE (No one lives forever.) says: > # rm -rf /usr/tmp > # ln -s /tmp /usr/tmp > Which prompts the question: what is the performance hit for translating the symbolic link? Many beginning system managers think they can mv /tmp to the /usr file system and then make a symbolic link. It can be done, but then they read in net.unix-wizards (pardon me, comp.unix.wizards) that this really hurts some programs. Is this a real concern? Will your compiles REALLY slow down? What's the straight scoop on name/link translation? (This is all assuming 4.xBSD). -- Chris Grevstad {sdcsvax,hplabs}!sdcrdcf!psivax!nrcvax!chris ucbvax!calma!nrcvax!chris ihnp4!nrcvax!chris Too many notes. There are just simply too many notes.
det@herman.UUCP (03/25/87)
In article <5695@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > The worst offenders (outside the 4BSD world) seem to be some text editors. Well, i know that in vi(1), one can do a ":set directory=/usr/tmp" or EXINIT="set directory=/usr/tmp" to get around that problem. derek
mangler@cit-vax.UUCP (03/30/87)
In article <816@nrcvax.UUCP>, chris@nrcvax.UUCP (Chris Grevstad) writes: > Which prompts the question: what is the performance hit for translating the > symbolic link? With NFS, it can be *very* high. We had 15 Suns sharing a single /usr, each getting 18 rwho packets per minute, and doing creat's on pathnames of the form "/usr/spool/rwho/whod.%s", with /usr/spool being a symbolic link. The server for /usr was spending 50% of its cpu capacity servicing these symbolic link lookups, day and night. You would be amazed what a chdir() in the right place can do. (It seems that just about everybody has come up with a similar fix, except Sun). Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck