gnb@uunet.uu.net (Gregory N. Bond) (01/18/89)
In article v7n97/11 weltyc@fs3.cs.rpi.edu (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.... I would NOT recommend this for two reasons: 1) It would be SLOW. /tmp is one of those places you use a LOT, and making it NFS mounted would have quite a noticable impact in editors among other things. 2) It would cause problems with duplicate names. Many shell scripts (and I assume programs) make unique tmp filenames based on the PID which is unique on a single workstation, but NOT guaranteed unique across a network. Imagine if two users started vi on different files on different machines, but with the same PID - disaster, or at least confusion, as both editors proceed to use the same tmp file to edit from.... Greg. Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net Uucp: {uunet,mnetor,pyramid,ubc-vision,ukc,mcvax,...}!munnari!melba.bby.oz!gnb
aad@stpstn.uucp (Anthony A. Datri) (01/18/89)
weltyc@fs3.cs.rpi.edu (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.... Beware the things in the rc scripts that do things with /tmp. rc normally removes everything in /tmp, so you may want to make a seperate directory within the parent for each client, and mount the appropriate subdirectory as /tmp on the client. This lets you pool the disk space without having to worry about conflicts. If you have users who use vi, you also want to consider the ex3.7preserve that rc runs. Lastly, you might want to consider the working file that rc.local creates when it munges the motd file, but I don't think that'll be affected by redirecting /tmp. As I see it, you'll want to move the cleanout of /tmp from rc to after the mount, as well as the ex3.7preserve if it's an issue with you. Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aad
montanaro@sprite.steinmetz.ge.com (01/25/89)
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)
dredge@labrea.stanford.edu (Michael Eldredge) (01/25/89)
>I wonder if anyone has tried using one NFS-mounted /tmp directory for a >group of machines.... We have all of clients setup using NFS mounted /tmp partitions. They are not (at least noticibly) slower than the ND mounted /tmp. (Besides when and if you ever go to 4.0.n it is all done with NFS anyway.) We did run some bench marks, setting one client with ND /tmp and one with NFS /tmp and ran some huge compiles and some editors, etc. and in one test NFS was faster; in another ND. So we really just rely on the user-impression metric. Our server exports 2 /tmp directories (on differnt controllers): /etc/exports: /tmp.nfs1 Clients /tmp.nfs2 Clients In each of these partitions are subdirectories named for the clients, e.g.: /tmp.nfs1/hitchrack/ /tmp.nfs1/cheshire/ /tmp.nfs2/talbotts/ Then each client, in /etc/rc.local after YP, routing, biod and before the "/etc/mount -vat nfs" call does: me=`hostname` case $me in [a-m]*) tmp=gloworm:/tmp.nfs2/$me ;; [n-z]*) tmp=gloworm:/tmp.nfs1/$me ;; esac /etc/mount -t nfs -o rw,hard,intr $tmp /tmp >/dev/console # -------------------------- /etc/mount -vat nfs >/dev/console So that the mount point is not at the root of the exported file system. We're happy with it. dredge Michael Eldredge Stanford Integrated Circuits Lab
dmcanzi@watdcsu.waterloo.edu (David Canzi) (01/25/89)
There are two solutions to this problem in use here (on machines that I have access to). Suppose your server is unimaginatively called "server" and your diskless (I assume) workstations are called "client1" and "client2". Both solutions involve mounting a file system under the root directory on server, as, say, /nfs_tmp, and creating the directories /nfs_tmp/client1/tmp and /nfs_tmp/client2/tmp. Then it is possible either (1) to mount server:/nfs_tmp/client1/tmp at /tmp on client1, and handle any other clients similarly, or (2) to mount /nfs_tmp on all clients, and make /tmp a symbolic link to the appropriate subdirectory of /nfs_tmp on each client. Since each client uses a separate directory as its /tmp, there are no problems with name collisions. Oh yes, the above solutions are implemented under SunOS 3.n, for various values of n. Whether this kind of trickery is possible -- or needed -- in SunOS 4.0.x, I don't know. Somebody has questioned the sanity of using nfs for mounting /tmp, on grounds of speed. If you have, say, 24 diskless workstations, being able to have all the workstations share a common /tmp file system makes it possible for users to create temporary files and directory structures that are much larger than the amount of disk space we can afford to allocate for root partitions for each of 24 workstations. And if, perchance, nfs is slower than nd, it probably isn't slower by much. David Canzi
bet@orion.mc.duke.edu (Bennett Todd) (01/31/89)
As Gregory Bond points out, there are problems with sharing an NFS-mounted /tmp directory over a network. The performance question is a real issue, except that diskless machines are getting to everything via the network anyway. I hate having /tmp be on root, and don't want a slew of additional partitions to give every machine its own /tmp, so I had every machine mount up one common /tmp partition via NFS. PID collisions could potentially have been a (rare) occurance; what bit me immediately was cutting and pasting between windows. Apparantly that is routed through a file (/tmp/winselection?) that has a fixed name. It was really amusing when users were cutting and pasting from each other's windows:-). My solution was to have everyone mount a common tmp filesystem on /nfs/tmp. This filesystem had subdirectories for each machine, so machine "orion" had a directory /nfs/tmp/orion. Finally I put symlinks in the root directories for each machine pointing to their tmp subdirectory. I haven't had any problems since. I really like sharing /tmp; whereas for one machine I'd want to have at least 4-5M free for tmp files, I haven't run into any problems sharing ~20M among a dozen machines. -Bennett bet@orion.mc.duke.edu