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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Dollens, Bruce
Sent: Thursday, July 31, 2008 9:16 AM
To: ADSM-L AT VM.MARIST DOT EDU
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?