I agree with what Zlatko and Juraj are saying. I just want to add that in disk subsystems such as ESS that do use RAID5 a lot of care has gone into the introduction of cache destaging algorithms that mitigate the write penalty. that is, writes are held in cache until they can be destaged sinchronously thus calculating the parity once per stripe. it is a sort of RAID3 style procedure. this does help, but the real performance problem is, as I said in another post, trying to get all arrays and adapters to work and spread the load across the machine. this does make a difference. it has to be said, though, that in real situations a RAID5 based machine will experience a performance loss of around 15-20 % compared to a RAID1 case. this is not avoidable. the thing to understand is that we should not compare RAID systems on a simple performance basis; the main reason for choosing RAID5 is, quite simply, cost. an EMC machine will cost loads more because it uses RAID1 (on top of the usual sky high EMC prices) when compared to a RAID5 based machine. in many cases the performance loss is acceptable so it's ok to go with RAID5; if performance is the issue, then the only logical choice is RAID10. I don't feel confident in leaving data with no protection, just as Juraj was saying. TSM's ability to have many parallel sessions will have to be considered together with the underlying hardware to come up with the best solution for the particular case. that's the keyword I think; rules of thumb and generalist approaches can only give us an order of magnitude for what we are doing, but really every case needs to be analysed on its own.
Cordiali saluti Gianluca Mariani Tech Support SSD Via Sciangai 53, Roma phones : +39(0)659664598 +393351270554 (mobile) [EMAIL PROTECTED] Zlatko Krastev <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ET> cc: Sent by: "ADSM: Subject: Re: allocating disk volumes on RAID5 array Dist Stor Manager" <[EMAIL PROTECTED] .EDU> 05/29/2002 03:27 PM Please respond to "ADSM: Dist Stor Manager" Juraj, I completely agree with you. But this is argument against RAID 5. The question is: if we accept presence of RAID 5 as a fact how to proceed further. Read-before-write penalty can be mitigated by tuning blocksize. OTOH TSM is using big writes and this should not pose so big problem for it. To be honest I personally avoid to put TSM volumes on RAID other than EMC/Hitachi/IBM disk subsystems. 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: Re: allocating disk volumes on RAID5 array 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..