1. chunk size 与 fs block size

传统来说，机械硬盘一个扇区是512个字节。所有的IO操作到了底层都会转换成512字节的大小。比如如果你需要读1000个字节，那么就需要2次IO操作。
后来出了4K扇区，以及512e。

同样的问题应用到raid上：raid盘做一次IO，每个硬盘上最小的IO单位我们称为chunk size。假如你有n个硬盘做raid5。那么逻辑上来讲一次IO会读或写(n-1)*chunk_size的用户数据。如果我们再和文件系统联系起来，一个文件的最小逻辑单元是一个block。 Linux上fs的一个block是4k或者更小。Windows上通常是4k、16k，64k之类的。所以在Linux上一般raid的一次读取或写入的数据量要大于fs的单位。如果你在raid5的盘上运行一个数据库，当你改写数据库的一个页面的时候，底层的raid存储需要先读(n-1)*chunk_size的数据，再修改，再写回。Linux通过优化文件系统的cache的方式来减少不必要的读取。实际性能受cache命中率的影响，但无论如何远远达不到硬件极限。

Windows从Win10开始开辟的另一条新途径：建议用户增大fs的block size使之与raid strip size匹配。比如假如你有5个盘，那么你就设置raid的chunk size为16K，fs的block size = 16*(5-1) = 64K。经我实际测试，这样的话可以达到4倍于单个硬盘的写入性能。比如，5个机械硬盘的raid5大概能达到1GB/s的顺序写入。但另一个问题来了，假如你有6个盘怎么办？由于6-1=5，而另一方面fs的block size都是2的次幂。所以无论如何你都找不到一个合适的匹配。为此Windows引起了一个新概念叫number of columns，指一次IO涉及几个硬盘。比如当你有6个盘时，它默认设置number of columns为5。这样4个是数据，一个是校验。在这种情况下，存储空间的有效率是4/5=80%，比Linux的5/6=83.3%低。但是IO效率更高了。如果用户不满意，可以去自己调整这个值。但是Linux的md似乎还没有提供这样的功能，也许它也不需要有这样的东西。

2. write cache
如果RAID5的一次写操作需要的字节数小于上面所说的(n-1)*chunk_size，那么它需要先把硬盘上现有的这段数据读进来，然后改写并计算奇偶校验，然后再写回去。这称为一个read-update-write cycle。使用cache可以缓解这个问题。

对于硬raid卡来说，write cache技术已经很成熟了。数据中心用的raid卡一般都是带电池的，数据一旦写入raid卡，便可以认为是安全了。但是一般这个cache只有1到4GB大小。随着现在硬盘越来越大，我很怀疑它有多大作用。

对于软raid来说，linux md允许你指定journal device。比如你可以拿一个SSD来加速写。但是这个SSD必须要质量很好才行。一般消费级别的SSD的写入寿命远远达不到要求。如果它还带电池，看起来就跟上述的硬raid卡差不多了。不过，就算是高质量的SSD，它也会坏。它坏了你的raid盘就完了。所以有人会建议用两块SSD做raid1来做journal device。但这个真是外行人的建议。linux md关于这些功能的代码非常不成熟。你去它们的邮件列表看，连作者们自己的都强烈不建议用，说这个feature太experimental了。我自己用的时候也屡屡遇到kernel死锁。这个时候只能强制拔电源。
--
修改:snnn FROM 107.139.34.*
FROM 20.83.74.*

"就算 bcache 设备坏了, 丢失的也是最后写入的数据" 你这说的是write-through和write-back的区别。write-through是说cache必须已经刷到raid盘上，才会向上层报告IO完成。 In this mode the cache disk isn't required to be big. Several hundreds megabytes are enough. 相反，write-back是说写到cache里就算完成了，这种如果cache盘坏了就会导致灾难性的后果。所以这种情况下cache盘要做raid1。 对硬raid卡来说，这个cache盘不会坏，没听说谁把这个写坏了的。但是对于软Raid拿SSD做写cache，如果使用的消费级的SSD，很容易就到写入寿命了。

--
FROM 107.139.34.*