schell@hazel.ucdavis.edu (Stephan Schell) (08/16/90)
Several months ago, I queried this group about /etc/umount'ing an NFS
file system when the server in question has gone off the net (e.g.,
crashed, become severely loaded, started to thrash). In such situations,
/etc/umount refuses to unmount the file system in question. One
person suggested using /etc/umount -f to "force" the umount operation,
but this is clearly preposterous since umount (under HP-UX 7.0 on
9000/835) does not recognize this option. The only fix seems to be to
reboot the machine. THIS IS LUDICROUS. If I can ungracefully terminate
my relationship with an NFS server via a reboot, why shouldn't I be able
to accomplish the same thing using umount and avoid the reboot (which
tends to greatly disrupt other users)?
--
-------------------------------------------------------------------------------
Stephan Schell schell@llandru.ucdavis.edu
Dept. of Electrical Engineering {ucbvax,lll-crg}!ucdavis!llandru!schell
& Compter Science
University of California, Davis (916) 752-1326tncsatr@dutrun.UUCP (Arthur van der Harg) (08/16/90)
In article <SCHELL.90Aug15105118@hazel.ucdavis.edu> schell@hazel.ucdavis.edu (Stephan Schell) writes: [...] |crashed, become severely loaded, started to thrash). In such situations, |/etc/umount refuses to unmount the file system in question. One |person suggested using /etc/umount -f to "force" the umount operation, |but this is clearly preposterous since umount (under HP-UX 7.0 on |9000/835) does not recognize this option. The only fix seems to be to |reboot the machine. THIS IS LUDICROUS. If I can ungracefully terminate |my relationship with an NFS server via a reboot, why shouldn't I be able |to accomplish the same thing using umount and avoid the reboot (which |tends to greatly disrupt other users)? | If I understand the problem well, the solution might be to specify 'soft' mounting when you mount the system. I gathered that in those cases your own machine wqould not be dependent on the (mal-)functioning of the 'home' machine of the file system. I expect (disclaimer: I am not completely sure) that in this case you can umount the system without waiting for a confirmation from the other machine. I think that the confirmation is the problem when the other machine goes down. Hope this helps! |Stephan Schell schell@llandru.ucdavis.edu -- /* The use of 'goto' statements is discouraged, especially with the label HELL: Arthur van der Harg (arthur@dutfdsa.tudelft.nl) */
rvdp@cs.vu.nl (Ronald van der Pol) (08/17/90)
schell@hazel.ucdavis.edu (Stephan Schell) writes: >Several months ago, I queried this group about /etc/umount'ing an NFS >file system when the server in question has gone off the net (e.g., >crashed, become severely loaded, started to thrash). In such situations, >/etc/umount refuses to unmount the file system in question. One Probably unmount(2) fails with an EBUSY error. This means there is at least one process which is trying to do IO on the NFS file system. You have to kill this process first, although it probably won't listen to a kill signal unless you have mounted the file system with the 'intr' option. These processes show up with ps(1) as (swapped out) processes in disc wait. -- Ronald van der Pol <rvdp@cs.vu.nl>
Kimmo.Suominen@lut.fi (Kimmo Suominen) (08/20/90)
>>>>> On 16 Aug 90 14:00:20 GMT, tncsatr@dutrun.UUCP (Arthur van der Harg) said:
Arthur> If I understand the problem well, the solution might be to specify
Arthur> 'soft' mounting when you mount the system. I gathered that in those
Arthur> cases your own machine wqould not be dependent on the (mal-)functioning
Arthur> of the 'home' machine of the file system. I expect (disclaimer: I
Arthur> am not completely sure) that in this case you can umount the system
Arthur> without waiting for a confirmation from the other machine. I think that
Arthur> the confirmation is the problem when the other machine goes down.
Sorry, you CAN'T umount even soft mounted NFS partitions. But they
won't cause you as much trouble as hard mounted ones, when a server
goes down. On the other hand you might have trouble in e.g. getting
your programs compiled, because on soft mounted links you get NFS
timeouts instead of trying until succesful.
Deciding between soft and hard links has many points to consider. On
a reliable network it is best to have hard links, but if the links
break down often, soft links make your life a lot easier.
NOTE: The manual tells to always use hard links on read/write
partitions. I haven't had problems, though, even if I run them soft
mounted.
--
Kim --- "That's what I think."