Path: utzoo!mnetor!uunet!steinmetz!vdsvax!barnett From: barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) Newsgroups: comp.unix.wizards Subject: Re: Lots of NFS cross mounts? Message-ID: <4155@vdsvax.steinmetz.ge.com> Date: 8 Apr 88 16:53:15 GMT References: <106600042@datacube> <753@xyzzy.UUCP> Reply-To: barnett@steinmetz.ge.com (Bruce G. Barnett) Organization: General Electric CRD, Schenectady, NY Lines: 56 In article <106600042@datacube> berger@datacube.UUCP writes: | | Does anyone have any experience with having many (30 or more) partions | cross mounted on many (30 or more) machines? Are there any impacts | that we should be aware of? Someone else mentions disabling the quota checks. YES!!! Another thing you can do ( besides wait for SunOS 4.0) is to keep the NFS partitons away from your searchpath. That is, include a /usr/local/bin in your searchpath, but avoid /usr/server/local/bin in case the server is down. (You will find it very frustrating when you can't open a new window if your .cshrc file sets the path to a down NFS partition). Instead, make a link from /usr/local/bin/prog or $HOME/bin/prog to /usr/server/local/bin/prog. This way, you will only get a timeout when you EXECUTE the program. Same thing with .rootmenu files - being unable to pop open your root menu is also frustrating. Another suggestion is to change the mount point from /usr/server to /home/server with a symbolic link from /usr/server to /home/server You don't have to change the /etc/fstab entry, BTW. what does this get you? - well, you can do this cd /usr ls -l du without getting hung on down NSF machines. Also - I believe SunOS 4.0 and BSD-4.3-tahoe are going to a similar structure. I have also learned to check out disk space with either df -t 4.2 or df & The rule is - avoid accessing 'wired' NFS mounts in your menus, search paths, shell scripts, etc. Current count of diskless Suns: 131 -- Bruce G. Barnett uunet!steinmetz!barnett