What I've seen in the past, in general, is that inbound work looking for a place to store data will bind to a defined TSM volume that is not currently in use. Now, knowing that volume name is an internal key within TSM you can prevent excessive TSM DB lock contention by breaking that storage pool up into as many tsm defined disk as you expect to have (max) inbound concurrent sessions. This will allow each one of them to tie to a defined disk for its current use. Having just a single, or limited number of defined disk will impact your performance.
Dwight -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Dollens, Bruce Sent: Thursday, July 31, 2008 9:16 AM To: [email protected] Subject: [ADSM-L] New TSM Layout We are in the process of designing our new TSM server. As part of this we are also going to give it new SAN drive space. Currently we have 661 Gig in our disk pool and we are upping that to 900 Gig. What our questions is how should we partition that? Our current pool is in 7 partitions but I was thinking more like 3 or 4 partitions. Are there any pro's/con's with going with fewer disk partitions?
