  Overhead of volume shadowing? 
 The Question is:
 
How much system overhead is created when volume shadowing is turned on?
 
 
 The Answer is:
 
  There are various sorts of overhead -- of relevence to this case are
  the amount of system resources used (in this case, memory) and the
  amount of extra processing required to set up, to maintain, and to
  do I/O to a shadow set.
 
  For memory:
 
  Some non-paged pool is required for each shadow set -- a structure is
  created for each -- it's relatively small.
 
  Some system memory is required to contain the shadow driver -- for a
  rough estimate of this memory, see the on-disk size of the shadowing
  driver itself.
 
  Some additional system physical memory is required by the shadow server
  process.  Some page file space is reserved.
 
  Some additional locks are created, and some additional SCS traffic is
  created to maintain those locks.
 
  For processing:
 
  Whenever you do an I/O operation, the operation is processed by the
  shadow driver before it is given to the member disk class drivers.
  The particular amount of additional overhead also depends on the
  read-write mix.
 
  For reads, the shadow driver picks one shadow set member and issues
  the read to that.  So, there's a little bit of additional processing
  before the read gets to the member class driver.
 
  For writes, the shadow driver issues a write operation to *each* of
  the member drivers, and does not complete the I/O operation until *all*
  members have completed it.  Thus, write I/O is only as fast as the
  slowest member -- if one member is at the end of a long communications
  link, this could be (relatively speaking) quite slow.  And there's the
  additional processing required to do 2 or 3 I/Os in place of the one
  original I/O operation.
 
  Most of the time, you don't notice the additional I/O overhead, because
  the additional processing time is buried in the time it takes to actually
  access the disk surface.
 
  The real overhead comes when some error occurs, or when an unusual event
  occurs.  The actual amount depends on what the event is, but here's a
  flavor of what may occur:
 
  1) you add a new member to an existing shadow set.  This will cause
  shadowing to initiate a copy from some other member to the new one.  If
  the members are large, this will be a substantial amount of I/O as the
  copy proceeds (which may take many tens of minutes; even hours, depending
  on the amount of data to be moved, and the performance characteristics of
  the disks and systems involved).  Note that this event may occur when you
  first create the shadow set.
 
  2) some error occurs which causes shadowing to throw out a member.  In
  this case, there is some SCS traffic, as the shadow drivers in each
  system accessing the shadow set communicate amongst themselves to decide
  which member to toss out.  Then there is a mount verification process to
  ensure the remaining members still make up a consistent set.
 
  3) some error occurs which causes shadowing to re-confirm the consistency
  of the shadow set.  This causes shadow driver to put the set into mount
  verify, which causes additional I/O operations to each set member to
  determine if the shadow set is still consistent and safe to use.
 
  There can also be system overhead resulting from shadow copy operations.
  A shadow copy occurs when the shadow driver determines that the data
  from one volume must be duplicated onto another volume, such as when
  a new volume is added into a shadow set or when an existing shadow set
  volume has been removed from and then later added back into a shadow set.
 
