home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18225 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  3.9 KB
  1. Path: sparky!uunet!ogicse!uwm.edu!fps.mcw.edu!post.its.mcw.edu!not-for-mail
  2. From: kcb@post.its.mcw.edu (Kent C. Brodie)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Bound volume sets: are they a bad idea?
  5. Message-ID: <1egbrqINNiqd@post.its.mcw.edu>
  6. Date: 19 Nov 92 03:28:58 GMT
  7. Article-I.D.: post.1egbrqINNiqd
  8. References: <1992Nov18.122133.1@rhodes.aero.org>
  9. Organization: Medical College of Wisconsin  (Milwaukee, WI)
  10. Lines: 74
  11. NNTP-Posting-Host: post.its.mcw.edu
  12. X-Newsreader: TIN [version 1.1 PL6]
  13.  
  14. singer@rhodes.aero.org wrote:
  15.  
  16. : >>As far as I can reason it out, the pro is some degree of load balancing 
  17. : >>between the disks, and no management hassles sorting out what to put where.
  18. : >>The con is a halved MTBF on the bound set. Backup shouldn't be a problem, 
  19. : >>both together will fit on one DAT.
  20.  
  21. Wrong.   Volume binding does NOT do much load balancing at all.  At the
  22. very least, you have absolutely no control over it.   My best example
  23. is our own shop....   we have humungous MUMPS.DAT files (on the
  24. order of several million blocks large), and we used to have bound
  25. sets.    Most of the time, the first (n-1) disks were totally idle,
  26. while the last disk in the set got absolutely pounded.   Your
  27. mileage will vary, of course.
  28.  
  29.  
  30. : >>Would anyone care to tell me what I've missed, or of any experiences (bad
  31. : >>or long-term OK) with a volume set like the one I'm considering?
  32.  
  33. long term?   NOT a real good idea, unless you can live with the
  34. failure of one of the members, which effectively trashes the entire
  35. set.     It all depends on your data.   We *had* to go to bound
  36. sets because of the size of our files.  (HUGE).   However,
  37. the "importance" of our data, and our system performance needs
  38. both rose enough, where we now use disk STRIPING (works damned well,
  39. in my opinion, and well worththe money), and we also use volume
  40. shadowing.  ($$$$$$$, but again, worth it for the peach of mind.
  41. And we *have* had enough failures to warrant it.)
  42.  
  43. In our volume-binding days, we lost 3 disks in five years, but
  44. each of those losses were "fatal" and unrecoverable, except for
  45. using the previous night's backup.
  46.  
  47. Could you live with that?   If so, then binding is fine...
  48.  
  49. : Cluster factor DOES not increase! The cluster factor is whatever must be at 
  50. : initialize time ($INIT/CLUST=x) which is not a function of the number of
  51. : devices, but rather the size of the device. Once you bound the volumes, 
  52. : you can verify this by doing $ SHOW DEVICE/FULL and also a $DIR/SIZE=ALL
  53. : You will see that they are both the same.
  54.  
  55. This is correct.  When adding VOLUMES, the cluster size does not
  56. increase.   However, a STRIPE SET is different.  It's not reeally
  57. volumes, but it *is* considered one extremely large SINGLE VOLUME.
  58. That's why the cluster size is larger, because of the SINGLE VOLUME
  59. size.    This is also why stripe sets can only be 8.5 GB large.
  60. That's the largest addressable space in VMS for a SINGLE disk volume.
  61.  
  62. With binding, however, you can get really really huge. (if you want..)
  63.  
  64.  
  65. : The simplicity of growing the set by simply adding more devices, and the 
  66. : backing up of a single logical device overrides the other considerations.
  67.  
  68. This is ONE area where binding had striping licked...  in a bound set,
  69. it's a trivial operation to add a disk to the set.   In striping,
  70. however, you have to back up your data, dissolve the stripe set,
  71. and re-build it from scratch (adding the new member, of course).
  72. If you have volume shadowing (as we do), this isn't a real big deal,
  73. but it is certainly time-consuming...
  74.  
  75. I've done both volume binding and disk striping and volume shadowing
  76. (phase I and phase II) for years, so feel free to ask me if you
  77. have any more questions.
  78.  
  79. --------------
  80. Kent C. Brodie - Sr. Systems/Network Manager        brodie@post.its.mcw.edu
  81. Information Technology Systems
  82. Medical College of Wisconsin                (414) 257-8769
  83. -- 
  84. --------------
  85. Kent C. Brodie - Sr. Systems/Network Manager        brodie@post.its.mcw.edu
  86. Information Technology Systems
  87. Medical College of Wisconsin                (414) 257-8769
  88.