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:[EMAIL PROTECTED] On Behalf Of Michael Green Sent: Saturday, November 15, 2008 11:40 AM To: [email protected] Subject: Re: [ADSM-L] Best use of disk storage On Sat, Nov 15, 2008 at 4:48 AM, Kelly Lipp <[EMAIL PROTECTED]> 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?
