home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18173 < prev    next >
Encoding:
Text File  |  1992-11-18  |  3.4 KB  |  59 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!sdd.hp.com!elroy.jpl.nasa.gov!news.aero.org!speedy.aero.org!rhodes.aero.org!singer
  3. From: singer@rhodes.aero.org
  4. Subject: Re: Bound volume sets: are they a bad idea?
  5. Message-ID: <1992Nov18.122133.1@rhodes.aero.org>
  6. Lines: 46
  7. Sender: news@speedy.aero.org
  8. Nntp-Posting-Host: rhodes.aero.org
  9. Organization: The Aerospace Corporation, El Segundo, CA. USA
  10. References: <27A00A05_002EA238.009632A7DEFF5100$192_2@UK.AC.KCL.PH.IPG> <1992Nov10.124211.6220@slcs.slb.com>
  11. Date: 18 Nov 92 12:21:33 PST
  12.  
  13. In article <1992Nov10.124211.6220@slcs.slb.com>, brydon@asl.slb.com (Harvey Brydon (918)250-4312) writes:
  14. > In article <27A00A05_002EA238.009632A7DEFF5100$192_2@UK.AC.KCL.PH.IPG>,
  15. > SYSMGR@IPG.PH.KCL.AC.UK writes:
  16. >>I am currently considering the idea of taking two 600Mb disks and binding
  17. >>them into a 1.2Gb volume set. Nagging at the back of my mind is something
  18. >>that I think I saw some time back on this list, to the effect that DEC
  19. >>recommend you don't use volume sets unless you want a few huge files 
  20. >>potentially bigger than a single volume. I can't find anything to this
  21. >>effect in TFM, though. In our case, there would be several thousand files,
  22. >>none bigger than 100K blocks and most a lot smaller. Partitioning the files
  23. >>(currently on one overloaded disk) would cause a fair degree of user confusion.
  24. >>
  25. >>As far as I can reason it out, the pro is some degree of load balancing 
  26. >>between the disks, and no management hassles sorting out what to put where.
  27. >>The con is a halved MTBF on the bound set. Backup shouldn't be a problem, 
  28. >>both together will fit on one DAT.
  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. > Several other posters have mentioned the MTBF aspect.  Also, keep in mind that
  34. > you are taking 2 'large' volumes and making them into one.  This effectively
  35. > increases the size of the cluster factor.  If it is 4 on one of these disks,
  36. > it will be 8 on the volume set (Same with a stripe set, too).  So if you have
  37. > a lot of files that are small (ummm, in fact, even if you don't), you will be
  38. > wasting an average of 4 blocks per file.  Even if this is not a concern in
  39. > terms of disk space, remember that disk read/write requests are done in
  40. > clusters, not in blocks.  If your application wants one block from disk, it
  41. > reads in the whole cluster.  Even if most of the cluster is 'unused' space on
  42. > the disk.
  43. I have been running bound sets for about 6 years, with several type of devices:
  44. RA81s, SI s and lately with Emulex  and MTI drives, which are about 1.8 and 2 
  45. Gbytes respectively. It sure increases your MTBF, but disks are quite reliable
  46. these days. 
  47. Cluster factor DOES not increase! The cluster factor is whatever must be at 
  48. initialize time ($INIT/CLUST=x) which is not a function of the number of
  49. devices, but rather the size of the device. Once you bound the volumes, 
  50. you can verify this by doing $ SHOW DEVICE/FULL and also a $DIR/SIZE=ALL
  51. You will see that they are both the same.
  52. The simplicity of growing the set by simply adding more devices, and the 
  53. backing up of a single logical device overrides the other considerations.
  54.  
  55. > _______________________________________________________________
  56. > Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
  57. > Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
  58. >        On a clear disk you can seek forever.
  59.