--fdj2RfSjLxBAspz7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi All,

A collegue and I in different parts of our organisation were discussing
the use of storage unit groups.  My philosophy is that you should have a
single storage unit per media server - robot pair set to use all drives
for sanity, with max multiplexing set at the highest you would want to go.
This is easy to manage and I think is the most efficient way to use your
drives.

The other theory put forward is that you have multiple storage unit groups
limiting each individual storage unit to one or two drives depending on
policy requirements.  My collegue says this has been used to resolve
problems where multiple policies using different volume pools want to run
to the same storage unit thereby causing some sort of exclusive lock.
This to me sounds like a bug because we tested it on our AIX 5.1 MP2
server and could not get it to fail (second policy running with a
different volume pool would simply cause a new tape mount and jobs would
keep running.

My collegue says that Veritas recommended storage unit groups to overcome
these lock out problems on their Solaris 5.1 media servers.  But I can't
for the life of me see how it would help.

The reasons for using groups that I know of are:
        - you have multiple robots and prefer one over the other but are
          happy to use both
        - you want to load balance the same robot across two or more media
          servers for a single policy
        - you have drive contention and want to set some crazy high
          multiplexing value on your last few drives so that drives don't
          fail

Are there any more?  Has anyone been told by Veritas to use groups to
overcome storage unit availability problems due to multiple
policies/volume pools?

Your comments appreciated.

Thanks,
Dale

--fdj2RfSjLxBAspz7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDfQGR/dB3EOgAfiQRAsdbAJ9mHrZWYzs2nuR5XK+TmL5sYe2FSgCfcNm1
4yNwjbhhcjXPLeWQWFSkJ6U=
=ysUc
-----END PGP SIGNATURE-----

--fdj2RfSjLxBAspz7--