I have few questions related to raid5. consider creating a raid5 device, say md0 with three disks.
After creation, you start writing into the disk. Here whenever a file size of say 1gb is written , how much of actual data size is written into the three disks.?
I understand xor calculation is made while carrying out the write( for recovery alone). If xor calculation is not done properly(say bug in xor calculation algorithm), will the write still succeed.?
During read, how the xor calculated value is used? OR in other words XOR calculated value is really used during read?
For 1gb of data, every piece is data is distributed across three devices , say first_piece into first device, second_piece into second device and then third xor calulated piece(of first and second piece) into the third device.? Is my Understanding correct?
Consider Linux as the OS used. Thanks!
500MB to each disk in this three-way R5 config, in smaller clusters than 500GB but 500GB overall. Your understanding of how the clusters are loaded across all disks is correct but remember that unlike R4 the parity data isn't written to a single disk but spread around the disks along with the real data. Oh and the OS is fairly irrelevant.
The XOR analogy is an easier one to understand and therefore teach than what actually happens (which varies between controllers by the way) but it's close enough. Either way don't forget that there's usually some form of read-after-write verification going on to ensure the data written is capable of being read again. But single-bit errors do happen yes, one of the many reasons why pros don't really like R5.
In addition to what Chopper3 has already written:
what you refer to as "pieces" of data is actually called "stripes" or "chunks" in RAID speak. The stripe size is usually a configuration option during volume creation time, typical values are in the range of 32 - 256 KB. I believe md uses 32KB as the default.
whether the XOR values are used or not is an implementation detail of the read algorithm and it is basically a tradeoff. Not using the parity for reads might mean longer service times if disks are busy. Using the parity for reads inevitably means more calculations and thus higher load. With a sufficiently sophisticated scheduler, it could take the current queue depths into account and send read requests to the disks with the lowest load even if they happen contain the parity portion of the data, but give preference to non-parity data if disk load is equally low.
the real reason why pros don't like RAID 5 is because it is as lame as a duck for the "random small write" type of I/O loads. But take a look yourself and read some of the documents from the BAARF site for a more detailed discussion