Internally, within TSM there will be DB locks against keys such as ~volume~
and to help avoid lock contention what I like to do is to have as many
volumes in a storage pool as I expect maximum concurrent inbound client
sessions writing to that storage pool.  So if you have a BACKUPPOOL that is
to accept the inbound nightly backups and you see 500 GB nightly from 10
nodes that push 5 concurrent sessions each I would allocate/assign 50
volumes at [500/(10*5)]=10 GB each  (or 25 at 20 GB each)

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Michael Green
Sent: Saturday, November 15, 2008 11:40 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Best use of disk storage

On Sat, Nov 15, 2008 at 4:48 AM, Kelly Lipp <lipp AT storserver DOT com> wrote:

> I would choose 2.  Using JBOD disks build a cachepool with enough space
for incrementals.

I'm surprised you suggest to use JBOD  for diskpools (cachepools as
you call them) I.e. diskpool volumes spread across
(sda,sdb,sdc|hdisk1,hdisk2,hdisk3) devices, if I get it right...
Does it provide any measurable performance edge over the use of same
amount of disks in RADI5 configuration? Doesn't it make the setup more
prone to disk failures? I.e. one morning you may discover that one of
the disks has died  and you've just lost significant amount of data
from last night incremental?

>With the rest of it built on RAID5, create onlinefile with devclass file.
Choose a volume size of 25GB and create all the >volumes manually rather
than having TSM create them for you on the fly.  This way you avoid
fragmentation.

Why do you choose 25G? Why not 50G? Is this because it makes
reclamation of FILE volumes easier? If so, then why not 10G?


>
> One last thing: you really need to use devclass file on the bulk of the
storage as the disk device class does not provide space reclamation with the
file device does.

Well, I was thinking about emptying the diskpools completely while
having CACHE=y enabled. That allows you to migrate all the data down
the hierarchy  while still having it available for restores.

Basically my original question boils down to  this: why would I want
to spend time on additional migration stages when using FILE devc
(i.e. disk>file>tape instead of just disk>tape) and on reclamation of
FILE stgpool, if what I can do is just create huge disk pools and
completely empty them every morning and still have 20T worth of data
on them with cache=y?