Um.  I don't really see what the issue is.

TSM is elegantly designed to automatically compensate for a disk pool
being too small on occasion by kicking in the migration to tape
automatically for you, based on the thresholds you set.
So it's working as designed.  

I think you may be working too hard to fix something that isn't broken?
Why do you consider the migration to be a problem, if your data is going
to end up on tape eventually anyway?     


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Daniel Clark
Sent: Wednesday, October 25, 2006 11:49 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Using FILE instead of DISK devclass to avoid disk
under-utilization

I just got a situation that requires yet another storage pool
hierarchy, and I am starting to run into the problem described in [1];
basically I have more than enough disk in aggregate to handle nightly
backup loads, but when partitioned between different disk-based
storage pools, on a nightly basis some of them are hardly used at all,
while others are above capacity, forcing a migration to tape.

An elegant solution using disk in the FILE rather than DISK devclass
is presented in [2]:

>When I get my new disk in, I plan to make a single RAID5 volume, and
make a
>directory on it for a FILE devclass.  I'll permit something large like
50
>mounts on that class, and I'll make the volume size somewhere around
250M.
>
>I'll define stgpools against this devclass, and I'll control their peak
size
>with MAXSCRATCH directives.  My 2G stgpool will have maxscratch=8, and
so on.
>
>This will give me most of the speed of my current solution (minus the
RAID
>overhead) and permit the stgpools to grow and shrink as demand varies.

However in [3] there is anecdotal evidence that for undefined reasons,
this just doesn't work well; however these messages are from 2000 /
ADSMv3, so I am wondering if anyone has any recent experience with
this kind of setup in TSM 5.2 or 5.3.

[1] Re: one stgpool migrates to two?
http://msgs.adsm.org/cgi-bin/get/adsm98/2564.html

[2] alternate plan for DASD primary pools...
http://msgs.adsm.org/cgi-bin/get/adsm0008/64.html

[3] Re: alternate plan for DASD primary pools...
http://msgs.adsm.org/cgi-bin/get/adsm0008/64/1.html

Thanks,
--
Daniel Joseph Barnhart Clark
http://www.pobox.com/users/dclark