wietse@wzv.UUCP (Wietse Z. Venema) (06/09/89)
In the recent past, several postings mentioned that
>... it is not a good idea to [NFS] mount fs's directly under root
but do not explain why that is a bad thing to do. Inquiring minds
want to know...
--
work: wswietse@eutrc3.uucp | Eindhoven University of Technology
work: wswietse@heitue5.bitnet | Mathematics and Computing Science
home: wietse@wzv.uucp | Eindhoven, The Netherlandskarl@giza.cis.ohio-state.edu (Karl Kleinpaste) (06/09/89)
wietse@wzv.uucp writes: In the recent past, several postings mentioned that >... it is not a good idea to [NFS] mount fs's directly under root but do not explain why that is a bad thing to do. Inquiring minds want to know... The problem is due to getwd(), or whatever routine is equivalent on your system, when a server is down. If you have NFS filesystems mounted directly under /, then getwd() will get stuck on the entries for down servers, timing out at best or hanging indefinitely at worst. The former is if you use soft mounts; the latter is the kiss of death if you use hard mounts. Our scheme here (borrowed in some ways from RFS concepts) is to mount NFS filesystems under /n/servername/something, so that, e.g., if I am in /n/dinosaur/0 when server `Flower' goes down, getwd() calls (such as when a new csh starts up) will not get hung as getwd() traverses directories upward, looking for the name of the directory where I am. --Karl
flee@shire.cs.psu.edu (Felix Lee) (06/11/89)
Avoiding NFS-mounts in the root directory is fine. Except that SunOS4.0 uses the /tmp/.getwd efficiency hack. Whenever /etc/mtab is updated, getwd() will try to stat() all the filesystems mounted to try to update /tmp/.getwd. If any NFS server is hosed, all getwd() calls will hang. This should happen rarely--/etc/mtab doesn't change too often. Except when you're using the automounter. Serendipity. Sigh. -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee