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?