Zlatko,
> Write rate for RAID 5 is (note) again
> N times faster than single disk speed but decreases with penalty for
> recalculation if parity (highly controller dependent)
Often this calculation is not correct,
since raid-5 will be written in blocks which are typically
larger than the size of an i/o request,
which forces a read request ahead of write operation
in order to preserve remaining data.
For example on an raid-5 array consisting from 3 disks
a single write requset (from the OS perspective of view)
consists from
1) read block from 2 disks, a half from the block from each disk
2) update block´s data with those from i/o request and recalculate
parity of the block
3) write block to 2 disks (half of to each disk) and write parity to
1 disks
SUM = 5 I/O requests in two serialized groups:
2 Inputs in paralel plus 3 Outputs in paralel
This results in typical raid-5 drives beeing slow when writing.
Those interested may have look at some comparisions
at http://www.icp-vortex.com/index_e.html -> performance,
all controllers tested were much slower when writing Raid5.
Raid beginners will find nice picture explanation under
same address -> support -> raid level description.
regards
Juraj
-----Original Message-----
From: Zlatko Krastev [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 29, 2002 7:56 AM
To: [EMAIL PROTECTED]
Subject: Re: allocating disk volumes on RAID5 array
Quick answer - only one big volume.
OK. I will start my thoughts on the subject with single drive example.
Which is better for single drive - one volume occupying the whole disk or
several files/raw devices defined as DISK volumes? Remember: disk devclass
has nothing to do with mount points and allows concurrent access for many
sessions.
When discussions on this list were about DB volumes the answer was: one
volume. Same for disk volumes - one big volume. TSM can write multiple
sessions' data simultaneously. It also pipes large quantities of data
using transactions so drive queue will be well fed. And if we create more
volumes TSM will attempt to write "in parallel" which would force the HDD
heads to jump across the disk.
Now back to RAID arrays. RAID 1/10 consist of 2xN disks and RAID 5 is N+1
disks. Read rate for RAID 1/10 is either N times HDD speed or 2N times
depending on controller. Write rate is N/2 or N times the disks' speed.
RAID 5 gives N times read increase. Write rate for RAID 5 is (note) again
N times faster than single disk speed but decreases with penalty for
recalculation if parity (highly controller dependent). Penalty for
stand-alone controllers is somewhat high and increases with number of
disks. IBM ESS is using many tricks to mitigate parity penalty thus write
speed is close to ideal N x HDD speed. (End of technology overview :-)
When large read/write from/to RAID array is performed it is spread to all
the disks. Operation on one end of RAID array will transform to many
simultaneous operations to the *one end of the disks*! Operation to other
end of the array will tranform into operations on *other end of disks*!
Thus you will again spend your server's time moving heads of *all* drives
back and forth. And if one drive is slower than the others it will slow
down the whole operation. That's why all drives in an array should be
equal.
So for simple RAID arrays (a controller with some disks) the answer is
simple as for one drive - make only one big volume. For complex systems
like EMC Symmetrix or IBM ESS also take into account other techniques
used. For ESS and Symmetrix the generic answer is: make several volumes to
spread the load across more internal disk groups. Do not increase the
number of volumes far beyond the number of disk groups within the box.
Hope you are not bored by this long explanation.
Zlatko Krastev
IT Consultant
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: allocating disk volumes on RAID5 array
Since a RAID-5 array shows up as one big filesystem, what's the best
strategy for determining how many and of what size disk pool volumes to
create for your primary disk storage pool? For the most part I don't think
it really matters unlike allocating volumes on individual disks but
perhaps
I'm not considering something.
Thanks..
