On Thursday November 9 2006 5:24 pm, Carlos E. R. wrote:
The Thursday 2006-11-09 at 15:54 -0500, Greg Freemyer wrote:
I don't know the details of how linux implements it but conceptually for the worse case with raid 5 (ie. scattered writes) to update a single block you have to:
Read original block (even if your updating it 100%) Read Parity Block Back-out the original block from the parity calculation (Simple XOR logic) Put the new blocks data into the parity calculation (Simple XOR logic) Write the new data block Write the new parity block
So it takes 4 i/o's to do a single logical write assuming scattered disk writes.
Question.
The data block, is it written to one disk, or is it split over two disks?
Carlos E. R.
The data and parity blocks should all be equal sizes. No block should span physical or logical barriers - in a well written RAID algorithm that is! This gets into the meat of a RAID implementation because the RAID software has to know how your controllers and drives are arranged. When initially formatting a RAID array there should not be any data/parity blocks spanning a physical device or a logical device. That would cause an I/O per device for any read or write that accesses that block of spanning data and cause an unnecessary bottleneck. Greg is also dead on with the IDE vs SCSI for RAID. SCSI is the way to go because you can have multiple initiators on each bus/channel. That means multiple commands can be sent down a SCSI bus and each drive will do what it has to do independently. IDE causes a dead stop to more than 1 I/O at a time on a channel. And we haven't even started down the paths of elevator seeks, ordered writes, tagged command queuing, etc. But again it comes down to "What's the budget?", what do we have to work with here and performance, protection or both? Stan