Question on RAID5 and RAID5 BCV Pools

I'm pretty sure the recommendation came from a desire to avoid your BCV workload affecting STD workload on the same spindles. You can achieve the same thing by carefully selecting the BCVs for your STD devices so that they are on different spindles anyway, with having to have ALL the BCVs segregated from the STDs.

This would probably be easiest if you have ControlCenter (using the Visual Storage View), but I'm sure someone else can describe a way to do this with either SE or SMC (with a bit more manual footwork).

When you say "predictable performance" are we just saying the worst the user may see is a momentary delay when the BCv split occurs. In my experience a split happens in seconds or less.

There is no real chance for data integrity issues...correct?

When I said predictable performance, I meant that by segregating the BCVs from the source on different disks, there is less chance that the workload on the BCVs will impact the workload on the source.

In many cases, I would recommend not segregating the BCVs from the source devices. By segregating, you limit the amount of backend disks the source devices are on, as well as the BCVs. With them all spread over all disks, every disk becomes less utilized and can therefore have better performance.

However then the workload on the BCVs could impact the workload on the source devices. If the workloads don't really peak at the same time, then it is most likely a non-issue.

At a high level, for optimal performance don't segregate, for the absolute most predictable performance, segregate.

OK...the majority of our systems that we would clone are on RAID1 storage (source). The clones would be on RAID5 BCVs (destination). The systems we put on RAID5 are lower end and would not be cloned under normal/regular circumstances anyway.

So I think I should be fine....
Please let me know if I am still missing your point.
I do appreciate your help

Allen AFAIK when you establish BCV without -exact or other special options, symcli and the code will pair the devices trying to avoid picking both STD and BCV from same drive.

Interesting to note, but not surprising. Me though... I'm a Control Freak. I define the pairs in advance so I always know who is paired with who. This is just part of our "culture" now

In case you are wondering we do this using device files.

I have to partially correct what I said ... Straight from S.E. manuals... Look point 3/4 and 6 below

As previously described, standard and BCV devices within a device group are
selected into pairs using a full establish. For your understanding of the software
behavior, the following detail the sequences of the pairing algorithm used by the full
establish SYMCLI processes:

1. If a BCV device is explicitly specified, pair it with the specified standard device.

2. If the -exact option is specified, pair the devices in the exact order that they
were added to the device group (refer to ¿Exact¿ on page 216).

3. If the optimize (-opt) option is specified, pair the BCV device such that it is on
separate disk adapters for improved copying speed (refer to ¿Local optimizing¿
on page 217). This option overrides all other pairing decisions.

4. If the remote optimize (-opt_rag) option is specified for a composite group operation,
pair the remote BCV device such that it is on separate disk adapters in
the remote Symmetrix array, and improving copying speed (refer to ¿Remote
optimizing option¿ on page 224). This option overrides all other pairing
decisions.

5. If an attached BCV device exists, for the specified standard device, use the attach assignment.
If the device specified was previously paired, use the previous pair assignment.
If the paired BCV device is not associated with the same device
group as the standard device, you must use the force option to override the
current pairing and pair the standard device with another BCV of equal size in
the device group.

6. If there were no previous pair assignments, then pair standard and BCV devices
that are of equal size.