Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!nic.MR.NET!srcsip!pavo!alarson From: alarson@pavo.SRC.Honeywell.COM (Aaron Larson) Newsgroups: comp.protocols.nfs Subject: Re: hard vs. soft mounts on Suns and Pyramids Message-ID: <21283@srcsip.UUCP> Date: 3 May 89 02:24:55 GMT References: <15766@bellcore.bellcore.com> <840@mtxinu.UUCP> <2626@elxsi.UUCP> Sender: news@src.honeywell.COM Lines: 33 In-reply-to: hedrick@geneva.rutgers.edu's message of 2 May 89 19:58:33 GMT In article hedrick@geneva.rutgers.edu (Charles Hedrick) writes: .... - pwd, getcwd, etc., should be coded so that they don't hang unless your current directory is actually on the hung server We've gotten around this particular bug (and in the process several related ones) by hard mounting our partitions in a rather indirect manner. On our machines /n is a directory where we (conceptually) mount all the remote file systems. If you ACTUALLY mount remote partitions in one directory you lose when one of the machines goes down. This happens because as the directory is scanned looking for machine foo, stat hangs on the down machine. We get around this by actually mounting the paritions in another directory structure, and link to them. For example our /n dir looks like: /n/foo -> mumble/foo/mp /n/bar -> mumble/bar/mp We mount foo's partitions on top of mumble/foo/mp, and reference them through /n/foo (the actuall structure is not important other than you must be sure that only one machines partitions are mounted in any one directory). Now, when the /n directory is scanned, the process won't hang because it won't actually stat a directory that has mount points until it finds the desired link. Since doing this, we've not had any problems with hanging processes unless they actually reference the partitions of a down host (as df and friends do). It even appears that the time spent following the links is more than offset by the time spent STATing the remote partitions! Aaron Larson MN65-2100 (612) 782-7308 Honeywell Systems & Research Center alarson@SRC.Honeywell.COM (internet) 3660 Technology Drive alarson@srcsip (uucp) Mpls, MN 55418 {umn-cs,ems,bthpyd}!srcsip!alarson