home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20015 < prev    next >
Encoding:
Text File  |  1992-12-29  |  2.6 KB  |  53 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!unixhub!slacvx.slac.stanford.edu!fairfield
  3. From: fairfield@slacvx.slac.stanford.edu
  4. Subject: Re: Mount verification timed out 
  5. Message-ID: <1992Dec29.105010.1@slacvx.slac.stanford.edu>
  6. Lines: 41
  7. Sender: news@unixhub.SLAC.Stanford.EDU
  8. Organization: Stanford Linear Accelerator Center
  9. References: <1992Dec29.152302.1716@das.harvard.edu>
  10. Date: Tue, 29 Dec 1992 18:50:10 GMT
  11.  
  12. In article <1992Dec29.152302.1716@das.harvard.edu>, chen@speed.uucp (Lilei Chen) writes:
  13. > In our VAX/VMS-cluster a bunch of disks are cross mounted.  Somtimes when
  14. > a node goes down, its disks are marked mount verification timed out.  I
  15. > haven't found a way to get those disks remounted without rebooting the
  16. > nodes.  I am wondering if someone on the net has a solution for that problem.
  17.  
  18.     For each node in the  cluster  for  which  the  disk(s) have gone into
  19. mount verification time-out, do:
  20.  
  21.     $ DISMOUNT/ABORT device
  22.  
  23. You can do this most easily from SYSMAN after doing
  24.  
  25.     SYSMAN> SET ENVIRONMENT/NODE=(NODE1,NODE2,...,NODEN)
  26.  
  27. where the node  list,  above,  includes  all/only  those  nodes needing to
  28. remount  the disk(s).  Follow the DISMOUNT with a MOUNT (with  appropriate
  29. parameters).  Note that it _is_ allowed to do a  second  MOUNT/CLUSTER  of
  30. the  device in question from it's local host (and perhaps from any node in
  31. the cluster, I haven't tried): all  nodes  for which the device is already
  32. mounted ignore the request, while nodes that don't have the device mounted
  33. will mount it.
  34.  
  35.     As another followup pointed out, if there are any open channels to the
  36. disk(s) that "went away", they must  be  closed  before the disk(s) can be
  37. dismounted.   That's  why  you need to use /ABORT.  I am not sure  of  the
  38. current situation (VMS V5.5-1), but in earlier versions  of  VMS,  if  you
  39. issued  a  DISMOUNT to the device _without_ the /ABORT qualifier, the disk
  40. would  NOT  dismount  successfully,  even  if  you  subsequently  issued a
  41. DISM/ABORT (again, this is most likely dependent on having "open" files on
  42. the device in question from the node you're trying to do the dismount).  I
  43. recall  getting devices into a state of "Mount/Dismount"!  The only way of
  44. recovering those devices for _that_ node was to reboot. :-(
  45.  
  46.         -Ken
  47. --
  48.  Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
  49.  SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
  50.  Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
  51.  ----------------------------------------------------------------------------
  52.  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
  53.