FWIW, here's the characteristics we use to split up our storage pools:

* Backup vs archive - we segregate archives from backups since their
retention (and subsequent reclamation) is so much longer than backups

* Library - obviously we need to have separate storage pool hierarchies
for separate libraries

* Simultaneous copy - some of our clients are so slow that they can't
make effective use of simultaneous copy, so we have a separate hierarchy
on one server for those systems that does not do simultaneous copy.

I guess in my mind a file from Windows is no different than a file from
UNIX, so it doesn't make sense to segregate storage based on source
platform.

-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine

On 05/08/13 12:43, Rick Adamson wrote:
> Hi Wanda,
> Note that in my situation not only were domains combined, but also storage 
> pools.
> Combining the domains resulted in more clients utilizing the same disk, 
> primary, and copy pools, which ultimately increased the time needed to 
> migrate, backup, and reclaim specific pools. The end result was the need to 
> revisit my admin task scheduling and in some cases disk pool sizes.
>
> Obviously, this may not be an issue for admins who use a single storage pool 
> structure for multiple domains but many systems I have run into have storage 
> pools dedicated by platform (following their domain model).
> So I just thought it worth mentioning....
> ~Rick