From: jsue@ncsa.uiuc.edu (Jeffrey L. Sue)
Subject: Re: Bound volume sets: are they a bad idea?
Originator: jsue@troon.ncsa.uiuc.edu
Organization: The Dow Chemical Company
Date: Fri, 20 Nov 1992 15:03:27 GMT

In article <102616@bu.edu> TEWKSBURY@BUDSGA.BU.EDU (Chip Tewksbury) writes:
>In <1egbrqINNiqd@post.its.mcw.edu> kcb@post.its.mcw.edu writes:
>
>> singer@rhodes.aero.org wrote:
>> 
>> : >>As far as I can reason it out, the pro is some degree of load balancing 
>> : >>between the disks, and no management hassles sorting out what to put where.
>> : >>The con is a halved MTBF on the bound set. Backup shouldn't be a problem, 
>> : >>both together will fit on one DAT.
>> 
>> Wrong.   Volume binding does NOT do much load balancing at all.  At the
>> very least, you have absolutely no control over it.   My best example
>> is our own shop....   we have humungous MUMPS.DAT files (on the
>> order of several million blocks large), and we used to have bound
>> sets.    Most of the time, the first (n-1) disks were totally idle,
>> while the last disk in the set got absolutely pounded.   Your
>> mileage will vary, of course.
>>...
>
>    Kent, Your response is partially correct.  Volume sets automatically
>    create new files on the volume in the set which has the most free space,
>    unless the creation is done with explicit placement.  If a system's file
>    sizes are relatively small and comparable, then excellent load balancing
>    at the file level will be realized from a volume set.  Striping won't
>    add much, if anything, to the load balancing performance if you have
>    smaller files of comparable size.
>
>    But as you said about your sight, if you primarily have "humungous"
>    files then the greatest benefit comes from striping.
>
>    "Your mileage will vary, of course."  And each site needs to identify
>    their system's file population  (and propagation) before jumping on the 
>    single physical volume, multi-volume volume set, or multi-volume stripe
>    set bandwagon.
>    			Chip Tewksbury.

Has anyone ever questioned DEC on their rather lackadaisical support of
bound volume sets in VMS?  I always found them extremely difficult to
work with when doing "operation" types of functions.  For example, try
doing a BACKUP/IMAGE from one volume set to another, with the output set
being a different number of volumes... good luck!  I doesn't work.
The only choice is to BACKUP [*...] from one set to the other, and this
took 16 hours to complete on a 3 volume RA82 disk (VMS 5.0 days).  I didn't
like that kind of downtime, and neither did my customers.

As to the I/O load-balancing:  If all of your files are fairly small, then
there is some load-balancing of the I/O due to files being placed on different
volumes.  However, if you have one or more files that are very active, then
I/O load-balancing is practically non-existent.  In this case, Striping has
been the only saving grace for us.

Basically, Striping gave us much better support in VMS for systems/operations
functions, and also much better I/O load-balancing.  As stated before, the
downside is that you can't *tune* the stripset without creating a new one
and copying the old one over to it (either disk-to-disk, or disk-tape-disk).
However, the overall I/O loading capacity is just about n*"disk saturation
point".  In other words, with 3 RA82s, which could handle 30 I/Os/second,
we could get up to 80-85 I/Os/second fairly easily before we started getting
queued requests.  Today's faster disks offer even more requests/second.
In fact, we saw the I/O bus become more of a bottleneck - so we switched
to the CIXCD controllers (over the CIBCA); and HSC70s switched from HSC50s.

Anyway, this has been my experience in the volumeset vs stripeset
controversy.



-- 
-----
Jeff Sue   
 - All opinions are mine -       (and you can't have any, nya nya nya)
Newsgroups: comp.os.vms