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:[EMAIL PROTECTED] On Behalf Of Daniel Clark Sent: Wednesday, October 25, 2006 11:49 AM To: [email protected] 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
