[ ... ] > The reasons are pretty well described in FreeBSD 4.11 vinum's > manual (which I had been using long before LSR): «… For optimum performance, stripes should be at least 128 kB in size: anything smaller will result in a significant increase in I/O activity due to mapping of individual requests over multiple disks.» That is a really gross generalization, because the aggregate latency due to lack of arm and platter synchronization among RAID members for example does not apply to flash SSDs, and has dramatically different impacts on read vs. write and streaming vs. randomish access patterns, and single vs. multiple threads workloads. The above recommendation applies mostly to reading, streaming, access patterns by single threaded workloads. However in those cases the argument is even stronger than it was in the past: the 'man' page makes example about disks with 6 (six) MB/s transfer rates and 8ms latencies, and current disks often exceed 100 (one hundred) MB/s, while access times haven't improved much. «A good guideline for stripe size is between 256 kB and 512 kB.» It is very important to note here that "stripe size" in Vinum means "chunk size" in MD. For many workloads that is too large a chunk size. «Avoid powers of 2, however: they tend to cause all superblocks to be placed on the first subdisk. …» — http://goo.gl/sTHxY > P. S. Alas, LSR doesn't support anything but powers of 2 for > chunk sizes, but according to Neil Brown, it can be relatively > easy changed. Some important Linux filesystems try to align metadata to chunk boundaries instead, for example 'ext3' with 'stride=' and XFS with 'su='. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
