Greetings, all.

I'm kicking around a near-total reconstruction of my disk pools, as we're
getting some new DASD in before too long, and I'll therefore have an "empty
tile" to play with.  I wanted to trot out the plan I was considering, and let
some other clue poke holes in it. :)


Currently, we've got ~54G of primary DISK pools.  These are partitioned in a
fairly copplex way, with the aim of maximizing the number of spindles I can
hand to my stgpools, regardless of their size.

So, a ~4G stgpool gets two 1.7G volumes, each on a different spindle.  My
biggest stgpool (18G) has four 4G and a 1.7G, each on different spindles.

And so on.

This is useful so long as I am correct in my incremetal-size estimations, but
I have to plan each stgpool for the "reasonable maxiimum" of an incremental,
which means that for some I have, say, 4G allocated but almost never use more
than 2.

So much for the sad story.  Now to what I plan to do about it:


When I get my new disk in, I plan to make a single RAID5 volume, and make a
directory on it for a FILE devclass.  I'll permit something large like 50
mounts on that class, and I'll make the volume size somewhere around 250M.

I'll define stgpools against this devclass, and I'll control their peak size
with MAXSCRATCH directives.  My 2G stgpool will have maxscratch=8, and so on.

This will give me most of the speed of my current solution (minus the RAID
overhead) and permit the stgpools to grow and shrink as demand varies.

I could even generate a second stgpool on the same AIX volume, for my dinky,
numerous workstation backups, with a volume size of ca. 100M, and colocate it.



Thoughts?  Is the raid5 on the stgpools a _drastic_ performance hit?  (my
bottleneck is currently the database, and then the network.  Disk speed is a
distant third)


Allen S. Rout