----> ... I rather NOT use RAID-5 for TSM disk pool volumes... Why pay the 
penalty
for calc & writing parity when you don't expect to read it more than
for calc & writing parity when you don't expect to read it more than
once?!? This data is so transient (in general, it exists for less than 48
hours)
it's not worth sacrificing ANY performance -- we really want to get the
backups AND migration done as quickly as possible, right?  These days, I
recommend RAID-0, striping without parity, if any at all; ...

Don,
on this list several people have had problems when something happened
before they completed daily BACKUP STGPOOL. If you define volumes over
RAID 0 array and only one disk fails you will lose many hundred GBs of
client backups. For some sites this might not be important and backups can
be restarted or wait for the next day's backup. But for others it can be
not possible. It is all about SLA you have.
And lets just imagine a situation - quaterly results are archived with
-deletefiles option and you RAID-0 drops a disk before primary pool backup
....
....
This is an imaginary situation but you can find more realistic one.

Zlatko Krastev
IT Consultant




Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: allocating disk volumes on RAID5 array

Wanda has identified the critical choices;  there is no single, right
answer
because the performance factors intersect at different points for nearly
every situation -- if only because most sites are at different points
along
the evolutionary development of IT infrastructure, different sized disks
for
RAID, different RAID technologies (ESS vs. EMC vs. native/local drives,
etc.), and different performance ranges for a given TSM server box.

And it does matter how you decide to carve up your disk pool resources.
Just
as different tape capacities & technology will influence your choices for
how tape pools are configured, variety in the type and capacity AND number
of channels accessing a set of disks will dictate the kind of performance
you can achieve.  So, if you think your TSM server system can handle 25
(50
in today's terms) sessions concurrently, then you measure the disk I/O
performance choices against that level of concurrency.  Most folks (these
days) disregard the effect of distributing many logical (TSM) volumes over
some number of physical volumes;  increasing the number of logical volumes
per physical gets that many concurrent writes queued to the device.  The
more of each, the more sessions can be sustained without waiting for
"mount-point".

I rather NOT use RAID-5 for TSM disk pool volumes... Why pay the penalty
for
calc & writing parity when you don't expect to read it more than once?!?
This data is so transient (in general, it exists for less than 48 hours)
it's not worth sacrificing ANY performance -- we really want to get the
backups AND migration done as quickly as possible, right?  These days, I
recommend RAID-0, striping without parity, if any at all;  on most
moderate
sized Unix machines, no striping at all, and as many smaller drives as can
be handled -- these days that translates to 36 or 72 GB drives, fill the
drive bays, get as much SCSI separation as possible... do the math on
dividing each physical drive into some 7-10 logical drives.  For RAID
anything, Gianluca's 7 or 8 physical drives per RAID config is a good
high-end count.


Don France
Technical Architect -- Tivoli Certified Consultant
San Jose, Ca
(408) 257-3037
mailto:don_france AT att DOT net

Professional Association of Contract Employees
(P.A.C.E. -- www.pacepros.com)