This came up in relation to this question on determining chunk size of an existing RAID array.
The general consensus seems to be that chunk size does not apply to RAID1 as it is not striped. On the other hand, the Linux RAID Wiki claims that it will have an affect on read performance. However, I cannot find any benchmarks testing/proving that. Can anyone point to conclusive documentation that it either does or does not affect read performance?
The article Optimal Chunk Size for Raid 1 and the zcav Benchmark has examined the question of chunk-size. Although dating from 2008, it has concluded that chunk-size makes no difference at all. In fact, he found out that the kernel actually completely ignores chunk-size.
I would conclude that chunk-size has no importance, and for RAID-1 disks performance considerations are the same as for ordinary disks, where performance is only dependent on sector- and block-sizes.
My logic says the same : I cannot imagine why a kernel would require two types of identical mechanisms - blocks and chunks. As far as I know, reads must be done in blocks, as the kernel cache is block-oriented (this explains the findings in the above article). Chunk-size could at most affect sector allocations on the disk, meaning that the allocation of files is done in chunk-sized units. Chunk-sizes for kernels that do that (if any exist) would then have an effect on disk fragmentation and file-sizes, but have marginal or no effect on read performance.
The only improvement in the performance of RAID 1 lies in its redundancy, when read requests are distributed between the two drives. But this has nothing to do with chunk-size.
The linux mdadm man page on Fedora 16 specifically says:
-c, --chunk=
Specify chunk size of kibibytes. The default when creating an array is 512KB.
To ensure compatibility with earlier versions, the default when Building and
array with no persistent metadata is 64KB. This is only meaningful for RAID0,
RAID4, RAID5, RAID6, and RAID10.
So, it has no impact on RAID1.
