home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18253 < prev    next >
Encoding:
Text File  |  1992-11-20  |  4.1 KB  |  84 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!ux1.cso.uiuc.edu!news.cso.uiuc.edu!jsue
  3. From: jsue@ncsa.uiuc.edu (Jeffrey L. Sue)
  4. Subject: Re: Bound volume sets: are they a bad idea?
  5. References: <1992Nov18.122133.1@rhodes.aero.org> <1egbrqINNiqd@post.its.mcw.edu> <102616@bu.edu>
  6. Message-ID: <1992Nov20.150327.11260@ncsa.uiuc.edu>
  7. Originator: jsue@troon.ncsa.uiuc.edu
  8. Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
  9. Organization: The Dow Chemical Company
  10. Date: Fri, 20 Nov 1992 15:03:27 GMT
  11. Lines: 71
  12.  
  13. In article <102616@bu.edu> TEWKSBURY@BUDSGA.BU.EDU (Chip Tewksbury) writes:
  14. >In <1egbrqINNiqd@post.its.mcw.edu> kcb@post.its.mcw.edu writes:
  15. >
  16. >> singer@rhodes.aero.org wrote:
  17. >> 
  18. >> : >>As far as I can reason it out, the pro is some degree of load balancing 
  19. >> : >>between the disks, and no management hassles sorting out what to put where.
  20. >> : >>The con is a halved MTBF on the bound set. Backup shouldn't be a problem, 
  21. >> : >>both together will fit on one DAT.
  22. >> 
  23. >> Wrong.   Volume binding does NOT do much load balancing at all.  At the
  24. >> very least, you have absolutely no control over it.   My best example
  25. >> is our own shop....   we have humungous MUMPS.DAT files (on the
  26. >> order of several million blocks large), and we used to have bound
  27. >> sets.    Most of the time, the first (n-1) disks were totally idle,
  28. >> while the last disk in the set got absolutely pounded.   Your
  29. >> mileage will vary, of course.
  30. >>...
  31. >
  32. >    Kent, Your response is partially correct.  Volume sets automatically
  33. >    create new files on the volume in the set which has the most free space,
  34. >    unless the creation is done with explicit placement.  If a system's file
  35. >    sizes are relatively small and comparable, then excellent load balancing
  36. >    at the file level will be realized from a volume set.  Striping won't
  37. >    add much, if anything, to the load balancing performance if you have
  38. >    smaller files of comparable size.
  39. >
  40. >    But as you said about your sight, if you primarily have "humungous"
  41. >    files then the greatest benefit comes from striping.
  42. >
  43. >    "Your mileage will vary, of course."  And each site needs to identify
  44. >    their system's file population  (and propagation) before jumping on the 
  45. >    single physical volume, multi-volume volume set, or multi-volume stripe
  46. >    set bandwagon.
  47. >                Chip Tewksbury.
  48.  
  49. Has anyone ever questioned DEC on their rather lackadaisical support of
  50. bound volume sets in VMS?  I always found them extremely difficult to
  51. work with when doing "operation" types of functions.  For example, try
  52. doing a BACKUP/IMAGE from one volume set to another, with the output set
  53. being a different number of volumes... good luck!  I doesn't work.
  54. The only choice is to BACKUP [*...] from one set to the other, and this
  55. took 16 hours to complete on a 3 volume RA82 disk (VMS 5.0 days).  I didn't
  56. like that kind of downtime, and neither did my customers.
  57.  
  58. As to the I/O load-balancing:  If all of your files are fairly small, then
  59. there is some load-balancing of the I/O due to files being placed on different
  60. volumes.  However, if you have one or more files that are very active, then
  61. I/O load-balancing is practically non-existent.  In this case, Striping has
  62. been the only saving grace for us.
  63.  
  64. Basically, Striping gave us much better support in VMS for systems/operations
  65. functions, and also much better I/O load-balancing.  As stated before, the
  66. downside is that you can't *tune* the stripset without creating a new one
  67. and copying the old one over to it (either disk-to-disk, or disk-tape-disk).
  68. However, the overall I/O loading capacity is just about n*"disk saturation
  69. point".  In other words, with 3 RA82s, which could handle 30 I/Os/second,
  70. we could get up to 80-85 I/Os/second fairly easily before we started getting
  71. queued requests.  Today's faster disks offer even more requests/second.
  72. In fact, we saw the I/O bus become more of a bottleneck - so we switched
  73. to the CIXCD controllers (over the CIBCA); and HSC70s switched from HSC50s.
  74.  
  75. Anyway, this has been my experience in the volumeset vs stripeset
  76. controversy.
  77.  
  78.  
  79.  
  80. -- 
  81. -----
  82. Jeff Sue   
  83.  - All opinions are mine -       (and you can't have any, nya nya nya)
  84.