如果磁盘有 512 字节的物理扇区，并且您有 10 个使用 RAID 50 且条带大小为 1MB的磁盘，这在磁盘级别如何工作？
如果我错了，请纠正我，但从概念上讲，将有 2 个跨度，每个跨度由 5 个磁盘的 RAID-5 阵列组成，一个镜像到另一个。因此，“条带”将包含 4x256KB 的数据块，以及每个条带的单个 256KB 奇偶校验数据？还是“条纹”包括奇偶校验？
如果您考虑 12 个磁盘的 RAID 10 阵列会怎样？将有 6 对镜像磁盘，并在这些镜像上进行条带化。因此，对于 1MB 的条带大小，条带将被除以 6，每个磁盘 174,762.666 字节，这相当于每个条带 341.333 个物理扇区。每个条带真的有 342 个物理扇区吗？
对于那些想知道我为什么要问的人；我试图确定相对于 RAID 类型最有效的磁盘数量，以及最佳条带大小。
另外，在问这个问题之前，我已经看过https://en.wikipedia.org/wiki/Nested_RAID_levels。事实上，我在大量 SCSI / SAS / RAID / SAN 供应商站点上进行了大量工作以寻找低级设计细节，但没有看到任何讨论实际磁盘上条带格式的内容。条纹只是在高度概念化的层面上讨论，这很好，但并没有真正回答问题。
您将在此处找到所有相关详细信息。
基本上，您的所有假设都是正确的：RAID 50 是 RAID 5 阵列的条带化 (RAID 0)，而 RAID 10 是 RAID 1 阵列的条带化。
然而，这是如何在物理上实现的，很大程度上取决于磁盘控制器。有时，额外的空间用于内部信息，因此除非您询问控制器供应商，否则您无法确切知道每个字节的使用方式、时间和地点。
关于条带大小：这几乎从不相关，除非您进行大量的性能调整；在这种情况下，它可能会产生影响，但它（再次）取决于您使用的控制器和磁盘，以及操作系统、文件系统和实际 I/O 负载。
As a rule of thumb, it's good practice to have the stripe size of the RAID array match the cluster size of the filesystem with which the volume residing on that array will be formatted; and that size should be chosen depending on the I/O load the volume is expected to handle (many small files or lots of big files?); but this is only a general suggestion; and, again, lots of other parameters can influence I/O performance.
Also, keep in mind that you could have multiple volumes on the same RAID array (even more so if you are working with a SAN instead of local storage), each of them potentially using a different cluster size and handling a different I/O load.
If you really want to fine-tune your storage to such a level, not only you will need complete control of each and every element from the physical disks to the actual application storing data on them, but you will also have to analyze them carefully and customize a lot of parameters, of which stripe size is only one of many.
A simple case study: Exchange writes database transaction logs as 1-MB files, sequentially; they are mostly written and rarely read under normal operation; they can take up some space, but never too much if regular backups are performed, because they get truncated (i.e. the oldest ones are deleted) everytime a full backup of the database is completed.
The best possible approach for storing this kind of data would be to use a RAID 1 array of two disks, with a stripe size of 1 MB, battery-backed-up write cache, a single volume formatted with the NTFS filesystem and 1-MB cluster size; oh, and of course you'll have to store only the transaction logs for a single database on this volume; if you have more DBs, you will need to use different volumes and disk arrays, or you'll lose all benefits of sequential I/O. (BTW, the actual database data must go to a whole different place, and not only for performance but mostly for data safety; have a look at the Exchange documentation if you want more details; but the basic points are, they have completely different I/O patterns and you absolutely don't want to lose both the database and the transaction logs at the same time.)
As you see, this kind of assessment is very strongly dependent on the expected I/O load, and wouldn't be adequate for anything else than storing Exchange transaction logs in a very specific setup; it will probably hinder any other workload.
Storage fine-tuning is an art, and requires lot of analysis and experience to get it correct.