Jakob Oestergaard wrote: >> >>When doing sequential writes, a small chunk size means you are more >>likely to fill up a whole stripe before data is flushed to disk, so it >>is very possible that you wont need to pre-read parity at all. With a >>larger chunksize, it is more likely that you will have to write, and >>possibly read, the parity block several times. > > Except if one worked on 4k sub-chunks - right ? :) > No. You probably want to look at the difference between RAID-3 and RAID-4 (RAID-5 being basically RAID-4 twisted around in a rotating pattern.) > > So, by making a big chunk-sized array, and having it work on 4k > sub-chunks for writes, was some idea I had which I felt would just give > the best scenario in both cases. > > Am I smoking crack, or ? ;) > No, you're confusing RAID-3 and RAID-4/5. In RAID-3, sequential blocks are organized as: DISKS ------------------------------------> 0 1 2 3 PARITY 4 5 6 7 PARITY 8 9 10 11 PARITY 12 13 14 15 PARITY ... whereas in RAID-4 with a chunk size of four blocks it's: DISKS ------------------------------------> 0 4 8 12 PARITY 1 5 9 13 PARITY 2 6 10 14 PARITY 3 7 11 15 PARITY If you only write blocks 0-3 you *have* to read in the 12 data blocks and write out all 4 parity blocks, whereas in RAID-3 you can get away with only writing 5 blocks. [Well, technically you could also do a read-modify-write on the parity, since parity is linear. This would greatly complicate the code.] Therefore, for small sequential writes chunking is *inherently* a lose, and there isn't much you can do about it. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
