Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!mailrus!husc6!rice!sun-spots-request
From: montanaro@sprite.steinmetz.ge.com
Newsgroups: comp.sys.sun
Subject: Re: Sharing /tmp through NFS
Message-ID: <8901181720.AA21289@sprite.steinmetz>
Date: 25 Jan 89 01:51:28 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 39
Approved: Sun-Spots@rice.edu
Original-Date: Wed, 18 Jan 89 12:20:33 EST
X-Sun-Spots-Digest: Volume 7, Issue 118, message 6 of 11

I replied directly to Chris Welty's original request (v7n97) on using a
shared NFS-mounted /tmp partition, but after reading Gregory Bond's
response (v7n108), I thought I'd post our solution to 'Spots.

Christopher A. Welty writes:
>I wonder if anyone has tried using one NFS-mounted /tmp directory for a
>group of machines.  I forsee possible problems with temp files names that
>have the same name, it would seem like a trivial thing to check for - but
>does sunos do it....

to which Gregory Bond replies:
>I would NOT recommend this for two reasons:
>
>1) It would be SLOW....
>
>2) It would cause problems with duplicate names....

We have been NFS mounting a large temporary partition for well over a year
with no ill effects. All machines using this scheme have /tmp defined as a
symbolic link to /temp/<machine-name>. /temp (note the 'e') is a 170+ MB
partition mounted via NFS. (It's that large because one of the clients
generates very large temporary files, not becuse we have umpteen zillion
machines sharing the disk space.) We notice no performance penalties. In
fact, you have no choice in 4.0.x but to have an NFS-mounted /tmp if you
are using a diskless workstation, so Sun has made the performance question
moot.  Isolating the various /tmp directories by machine name avoids name
clashes.  Another server and its clients use a similar scheme, but place
the /tmp directories within the same partition as the users' files (a 320+
MB partition about 80% full), again, using machine name to avoid name
clashes.

A nice side effect is that our root partitions (this is SunOS 3.4 and 3.5)
are smaller, typically under 5 MB, with 3-4 MB used, but with a bit of
attention to /usr/adm/messages and such we could make them even smaller
(2-3 MB?). I realize this argument goes away (sort of) in 4.0 and that
other techniques (like use of hard links) are available to reduce the root
directory tree size dramatically.

Skip Montanaro (montanaro@sprite.steinmetz.ge.com, montanaro@ge-crd.arpa)