No need to apologize - it's an interesting question, and I'm not totally
certain of the answer either.
Can someone else be authoritative?

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Tab Trepagnier
> Sent: Thursday, August 30, 2001 12:53 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: TSM DB/Disk Pool - Disk tuning question
>
>
> Lindsay,
>
> The "locked volume" is my understanding based on what I've observed and
> picked up from the list and the manuals. If that is wrong, I apologize.
>
> My set of 500 MB volumes is spread across six physical disks so I do get
> some load balancing.
>
> I think my system is network-bound anyway. The TSM server is on a 100 Mbs
> link.  Running topas, I've seen the newest IBM 18 GB SCSI drives WRITE at
> 12 MB/s.  Since almost all of my disk pool volumes are on 18Gs, I doubt
> that disk performace will limit the system's throughput.
>
> Thanks.
>
> Tab
>
>
>
>
>
>
>
> Lindsay Morris <lmorris AT SERVERGRAPH DOT COM>@VM.MARIST.EDU> on 08/30/2001
> 11:42:57 AM
>
> Please respond to lmorris AT servergraph DOT com
>
> Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
> To:   ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject:  Re: TSM DB/Disk Pool - Disk tuning question
>
>
> Do sessions really lock volumes?
>
> I had always assumed they didn't.  Disk volumes are random access, so for
> some reason I thought that several sessions could share one disk volume.
> In
> fact, I know of one site that regularly has 45-50 backup sessions running
> simultaneously, but only 37 disk volumes... so I'm not sure that's true.
>
> I DO believe that each new session tries to get a NEW disk volume to use;
> thus TSM tends to balance out the nightly backup load across its disk
> volumes.  Maybe that's the behavior you were seeing?
>
> If that's right (Andy Raibeck? is it?), then putting 36 500MB volumes on
> one
> 18 GB disk would encourage TSM to use that one disk for all of its backup
> sessions - a bad thing.
>
> The more common wisdom is to make volumes that take up the entire physical
> disk.  The only problem there is that you have less flexibility:
> if, in the
> future, you need to reapportion space between, say, your DB and a storage
> pool, you have to move  an entire volume.  I like to cut things up into 2
> GB
> chunks; that avoids the requirement for a BFS-enabled filesystem, too.
>