From: kcb@post.its.mcw.edu (Kent C. Brodie)
Newsgroups: comp.os.vms
Subject: Re: Bound volume sets: are they a bad idea?
Date: 19 Nov 92 03:28:58 GMT
Article-I.D.: post.1egbrqINNiqd
Organization: Medical College of Wisconsin  (Milwaukee, WI)
NNTP-Posting-Host: post.its.mcw.edu
X-Newsreader: TIN [version 1.1 PL6]

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.


: >>Would anyone care to tell me what I've missed, or of any experiences (bad
: >>or long-term OK) with a volume set like the one I'm considering?

long term?   NOT a real good idea, unless you can live with the
failure of one of the members, which effectively trashes the entire
set.     It all depends on your data.   We *had* to go to bound
sets because of the size of our files.  (HUGE).   However,
the "importance" of our data, and our system performance needs
both rose enough, where we now use disk STRIPING (works damned well,
in my opinion, and well worththe money), and we also use volume
shadowing.  ($$$$$$$, but again, worth it for the peach of mind.
And we *have* had enough failures to warrant it.)

In our volume-binding days, we lost 3 disks in five years, but
each of those losses were "fatal" and unrecoverable, except for
using the previous night's backup.

Could you live with that?   If so, then binding is fine...

: Cluster factor DOES not increase! The cluster factor is whatever must be at 
: initialize time ($INIT/CLUST=x) which is not a function of the number of
: devices, but rather the size of the device. Once you bound the volumes, 
: you can verify this by doing $ SHOW DEVICE/FULL and also a $DIR/SIZE=ALL
: You will see that they are both the same.

This is correct.  When adding VOLUMES, the cluster size does not
increase.   However, a STRIPE SET is different.  It's not reeally
volumes, but it *is* considered one extremely large SINGLE VOLUME.
That's why the cluster size is larger, because of the SINGLE VOLUME
size.    This is also why stripe sets can only be 8.5 GB large.
That's the largest addressable space in VMS for a SINGLE disk volume.

With binding, however, you can get really really huge. (if you want..)


: The simplicity of growing the set by simply adding more devices, and the 
: backing up of a single logical device overrides the other considerations.

This is ONE area where binding had striping licked...  in a bound set,
it's a trivial operation to add a disk to the set.   In striping,
however, you have to back up your data, dissolve the stripe set,
and re-build it from scratch (adding the new member, of course).
If you have volume shadowing (as we do), this isn't a real big deal,
but it is certainly time-consuming...

I've done both volume binding and disk striping and volume shadowing
(phase I and phase II) for years, so feel free to ask me if you
have any more questions.

--------------
Kent C. Brodie - Sr. Systems/Network Manager		brodie@post.its.mcw.edu
Information Technology Systems
Medical College of Wisconsin				(414) 257-8769
-- 
--------------
Kent C. Brodie - Sr. Systems/Network Manager		brodie@post.its.mcw.edu
Information Technology Systems
Medical College of Wisconsin				(414) 257-8769