eli@spdcc.COM (Steve Elias) (03/09/90)
apparently, it's a feature of HP-UX to be very stubborn if an nfs mounted disk goes away... everything starts going to pieces when this happens, and one workstation after another hangs up -- even if the workstation is not referencing the mounted nfs disk at all. does 7.0 do anything nicer when an nfs mounted disk goes away? whenever this happens, we can't simply unmount the disk, because it is "busy"... (i'm sure some workstation or other is actually keeping it busy, but why should *all* workstations freeze after a while?) -- /* eli@spdcc.com ; 617-932-5598 */ /* Aye sir! And a weeeeeeeee bit more. */
tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) (03/13/90)
> apparently, it's a feature of HP-UX to be very stubborn if an > nfs mounted disk goes away... everything starts going to pieces > when this happens, and one workstation after another hangs up -- > even if the workstation is not referencing the mounted nfs disk at all. One thing that will help is to _avoid nfs mounting a disk to root_. Instead, create an nfs subdirectory and nfs mount things there. # mount hpfoo1:/foodisk /foodisk # not good. - In this case, system hangups are possible if hpfoo1:/foodisk goes away, even if you don't formally access /foodisk. I suspect most resolutions of absolute path names (ie, /lib/cpp) requires a scan through /. If a hung mount is hit before the desired file is found, you have a nasty hang. # mount hpfoo1:/foodisk /nfs/hpfoo1/users # better. Avoids most hangups - This should protect you unless you make a formal access of the mount. You might want to consider soft mount and retry timeouts also in either case. Thomas Gilg tomg@cv.hp.com
tsuia@spock (Alan Tsui) (03/13/90)
In article <2008@ursa-major.SPDCC.COM> eli@ursa-major.spdcc.COM (Steve Elias) writes: >does 7.0 do anything nicer when an nfs mounted disk goes away? Try soft mount, with long timeout, or use automount [from Berkely]. -- Alan Tsui (613) 592-2122 Kanata, Ontario, Canada ...!uunet!mitel!tsui
jack@hpindda.HP.COM (Jack Repenning) (03/14/90)
Note that the strategy of mounting things in /nfs/hostname protects you from tripping over dead NFS mounts whenever you try to access a plain file, but it doesn't necessarily protect you from tripping over dead NFS mounts when you access a (live) NFS file. In general, the problem is that you may have trouble whenever accessing the hung mount itself, or any other file or directory in its parent directory. You can buy that kind of protection by not mounting other system's root (so now we have two rules: never mount to your own root, and never mount someone else's root). But that's no consolation if you actually need to get to the other system's root. You could get this protection by introducing a phantom level of directory: mount things to "/nfs/hostname/root" and below (e.g., the other system's passwd file would be /nfs/othersys/root/etc/passwd). In this case, you would only stumble across the hung mount when accessing othersys. However, there are still an annoying number of meanings for "access" that you might not have thought of. For instance, if the hung mount (or any sibling) is in your $PATH, it may get "accessed" while trying to find a command that's really elsewhere, and it will get "accessed" by every csh that ever starts. ------------------------------------------------------------- Jack Repenning - Information Networks Division, Hewlett Packard Company RFC-822: jack@hptnjar.cup.hp.com uucp: ...!hplabs!hptnjar!jack HPDesk: Jack REPENNING /HP6600/UX USMail: 43LN; 19420 Homestead Ave; Cupertino, CA 95014 Phone: 408/447-3380 HPTelnet: 1-447-3380 -------------------------------------------------------------