home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20140 < prev    next >
Encoding:
Text File  |  1992-12-31  |  4.3 KB  |  91 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!geraldo.cc.utexas.edu!slcs.slb.com!BRYDON@128.58.42.3
  3. From: brydon@asl.slb.com (Harvey Brydon (918)250-4312)
  4. Subject: Re: Mount verification timed out
  5. Message-ID: <1992Dec31.115043.1445@slcs.slb.com>
  6. Sender: news@slcs.slb.com (News Administrator)
  7. Nntp-Posting-Host: 129.87.186.2
  8. Reply-To: brydon@dsn.SINet.slb.com
  9. Organization: Schlumberger/Anadrill Sugar Land, TX
  10. References: <1992Dec29.152302.1716@das.harvard.edu>,<30DEC199208223472@spades.aces.com>
  11. Date: Thu, 31 Dec 92 11:50:43 GMT
  12. Lines: 77
  13.  
  14. In article <30DEC199208223472@spades.aces.com>, system@spades.aces.com (SYSTEM
  15. MANAGER) writes:
  16. >In article <1992Dec29.152302.1716@das.harvard.edu>, chen@speed.uucp (Lilei Chen) writes...
  17. >#In our VAX/VMS-cluster a bunch of disks are cross mounted.  Somtimes when
  18. >#a node goes down, its disks are marked mount verification timed out.  I
  19. >#haven't found a way to get those disks remounted without rebooting the
  20. >#nodes.  I am wondering if someone on the net has a solution for that problem.
  21. >#Thanks.
  22. >
  23. >    Short:    Increase SYSGEN parameter MVTIMEOUT to the time
  24. >        it takes one of your nodes to crash and reboot 
  25. >        plus a minute
  26.  
  27. I disagree with this advice.  I think you mean the time it takes the slowest
  28. node in the cluster to crash and get to the reboot code that re-mounts the
  29. disks (plus a minute) but I disagree with that too.  I set MVTIMEOUT to the
  30. max value on my clusters.  More below.
  31.  
  32. >    Long:    Mount verification is what VMS does to a device
  33. >        it isn't sure is responding.  After a certain 
  34. >        period of time where the device does not complete
  35. >        mount verification, mount verification timeout
  36. >        occurs.  (This timer is controlled by the parameter
  37. >        mentioned above). 
  38. >
  39. >        If you set the timer short, then as soon as a disk
  40. >        times out, all IOs to it are returned, no processes
  41. >        get to issue new IOs to the disk, and nobody hangs.
  42. >        The bad side of this is that even if the node serving
  43. >        this device comes back, the device is inaccessible.
  44. >
  45. >        If you set the timer long, then it will survive across
  46. >        reboots (the device will) but all processes with pending
  47. >        IOs will hang until timeout.
  48.  
  49. The above 'objectionable' behaviour is not always bad.  If it is a backup
  50. writing to the disk, for example, it will indeed hang if the disk goes
  51. offline, but (for my systems) this is preferable to getting the I/O's
  52. returned and aborting the backup of the disk.  Other situations apply.
  53. Generally, the cleanup for a disk in mount verification is bad enough that I
  54. don't recommend putting anything on satellite disks that would be used by
  55. anything but that satellite system (except things like backup).  If you ever
  56. put things like cluster-wide installed images, user directories, etc. a mount
  57. verification timeout can sometimes require a reboot of numerous cluster
  58. members, or even the entire cluster.
  59.  
  60. Mount verification timeout always requires manual intervention to fix.  I
  61. haven't found a good way of automating things that can be handled by a command
  62. procedure.  A disk in mount verification (with no timeout) fixes itself when
  63. the system reboots again.
  64.  
  65. Also, you only assume the case of a system crashing and rebooting.  The MV
  66. timeout would also occur if (say) you shut down the system manually, or it
  67. hangs, or the network is disrupted.  I recommend the highest possible value
  68. for MVTIMEOUT (about 17 hours?).  I wish DEC allowed an infinite value for it.
  69. Most of my massive cluster reboots occur Monday morning because of this...
  70.  
  71. As George Bush would say:
  72. "Mount verification, GOOD"
  73. "Mount verification timeout, BAD"
  74.  
  75. I participated in an extended discussion on this on comp.os.vms about a year
  76. ago with a few more details.
  77.  
  78. By the way, take note that MV timeout only occurs on a given node when it
  79. 'discovers' that a given disk is offline.  As far as I know, this only happens
  80. when you try to do I/O to the disk.  And every node in a cluster has its own
  81. opinion of the state of the disk.  A disk can be timed out on one node and not
  82. on another.
  83.  
  84. >    I would try and minimize the crashing of your other nodes...
  85.  
  86. Agreed.
  87. _______________________________________________________________
  88. Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
  89. Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
  90.     Sorry, but my karma just ran over your dogma!
  91.