==> On Fri, 11 Feb 2005 15:38:58 -0500, "Martinez, Matt" <matt AT IDEXX DOT 
COM> said:

> I have an opportunity to redesign the disk pool and db layout of our TSM
> Server , and I was wondering if my fellow TSMers can help me with it. First
> things first our environment is as follows, TSM Version: 5.1.7 soon to be
> 5.2.? on Win2k, the Disk the DB will be stored on will be a RAID 5 Disk on a
> EMC CX700 array.

> My main question is can TSM read/write multiple streams to a single Disk or
> DB vol?

Multiple backup streams to a DISK stgpool volume: Yes.

Multiple streams to a DB vol: not well formed question: there aren't streams
of data hitting the DB vols.

I suggest you hit the archives for some of the older discussions about
optimization points for DB volumes.  My own solution to these has been to
deploy a large number of relatively slow spindles for DB, and some very fast
disk for recovery log, but that's a completely different hardware regime.


> The reason I would do this is to optimize the I/O across all the
> spindles.


If you want to have large RAIDs (to minimize loss of space to parity drives)
then you might as well have large volumes as small.  While there are multiple
streams permitted to hit a DISK volume at a time, there's only one thread of
execution talking to a given volume at a time.  This means that if you have
two volumes in the same stgpool on the same RAID, that you're going to
engender some contention.

If you've only got one volume in the stgpool, then you've serialized on the
stgpool, which isn't so bad because you need to serialize on the underlying
RAID anyway.

To solve this on my own system, I've got my SSA chopped up into 5-disk RAIDs,
which I understand to be a performance sweet-spot for 36-G SSA disks.  Then
every DISK pool I've got has a volume on each RAID.  It's really kind of cool
to watch a high-throughput session run, because you can see a throughput spike
drift from RAID to RAID as the incoming session round-robins through the
available disk volumes.


- Allen S. Rout