今天，西⽠哥来谈谈⾼端存储的⼀股势⼒，RAID 2.0，最近被华为HVS搞得风⽣⽔起，神奇的让⼈摸不着头脑。我还是从⼀个⾼端存储的江湖说起吧。据说很久很久以前（别扔臭鸡蛋，讲故事都是这样的…）,L国王有个美丽的D公主(代表数据库DB)，特别喜欢吃西⽠果盘(代表主机看到的LUN)，饭量惊⼈，⼀次可以吃2个。D公主吃⽔果有⼀个懒习惯，就如泰国⼈⼀样，⽔果都是切成⼩块（Extend）后拼成果盘（LUN)，⽤⽛签吃。D公主还有⼀个⼩脾⽓，这个果盘如果有⼀⼩块是坏的，就整个果盘扔掉(代表数据丢失)。L国王特别宠爱D公主，找了EMC/IBM/HDS来做长⼯，专门负责做果盘。⽠地和宫殿有⼀段距离，他们每天都摘3个西⽠，2个⽤来吃，1个⽤来备份，万⼀那个⽠坏了就补上（代表RAID 5）。就这样，他们每天⾟苦在宫殿和⽠地奔波，碰到坏⽠还得回去⽠地拿备⽠（重构），⾮常⾟苦。D公主⼀天天长⼤了，饭量也越来越⼤，⽠也越来越⼤。但问题来了，每次碰到坏⽠，他们去搬备⽠需要10个⼩时，因为西⽠太沉了，路上⾛不快。D公主后来受不来了，让L国王把他们撤了，换成了3PAR和HW，3PAR和HW⽐较聪明，他们想，为什么我到宫殿再切⽠呢，我可以每个⽠切成20⼤块（Chunk），找20个⼈搬到宫殿后再切⼩块（Extend）后拼成果盘(LUN)不就可以了吗？到宫殿后如果发现⽠坏了，派⼈回来拿1⼩块换上不就可以了吗？这样需要搬的⽠只有原来的1/20，⽠轻了，路上可以跑，因此就算⽠坏了，半⼩时也就换回来了。D公主很满意，⽇⼦相安⽆事，直到有⼀天HW加班病倒了，⽽3PAR正好和HP谈恋爱请假了，⽆奈找了个年轻⼈叫XIV做临时监⼯，这家伙⽐较浪费，每次都挑4个⽠，在⽠地全部切成⼩块（Extend)，找⼀群⼩孩直接送给宫殿。对于D公主当然好了，但每次也只能吃⼀半，另外⼀半就倒掉了，很是可惜。后来XIV由于长得漂亮，被IBM包养，这是后话。好来，故事讲完了，⼤家知道RAID 2.0是怎么回事了吧？还扔臭鸡蛋，别，我来好好给⼤家讲⼀讲，刚才是讲故事呢。⼤家知道，传统的RAID 5过程是这样的：
选⼏个硬盘—》做成RAID 5—》根据容量创建LUN—》映射给主机（为了⽅便，我们称这个为RAID 1.0吧)
话说当时主流的⾼端⼚商，EMC/IBM/HDS全是这个⽅案。这种⽅式就是如果有盘坏了，只能这个磁盘组的硬盘参与重构。当时的硬盘⼀般都是⼏⼗G，⽽且全部是FC磁盘，问题并不严重。
但是现在⾼端都引⼊了SATA磁盘，现在的西⽠，不对，是硬盘越来越⼤，因此，当⼀块硬盘坏了，只有这⼏块硬盘参与重构，重构的时间1TB需要10⼩时，如果是4TB的SATA盘，更加不可想象。
除了重构时间外，RAID 1.0还有⼀个⼤问题，就是性能。⼀个LUN的读写只能在⼀个磁盘组进⾏，让后⾯加⼊的SSD等新的介质发挥不了作⽤。但EMC/IBM/HDS在RAID 1.0已经积累了⼗⼏⼆⼗年，RAID⼜是所有软件的基础，他们轻易不敢重写代码。怎么办？有了，可以把多个RAID组再组成⼀个池，再切⼀次（条带化）：
选⼏个硬盘—》做成RAID 5—》选多个RAID 5组成⼀个池—》切分为相等的⼩块Extend—》选择Extend组成LUN，映射给主机（为了⽅便，我们称这个为RAID 1.5吧)
RAID 1.5很好地解决了性能的问题，因为⼀个LUN的读写同时跨越了很多的硬盘，⽽且这个LUN⾥⾯可以包含多个RAID组，也就可以有多种磁盘介质，可以做到⾃动分层存储。但是，由于RAID组还是基于硬盘的，这块硬盘坏了，只有⼀个RAID组的⼏个硬盘参与重构，因此重构速度依然和RAID 1.0⼀样。
3PAR和华为，历史包袱不⼤，因此采⽤块的虚拟化技术RAID 2.0来解决这个问题（3PAR内部叫FAST RAID)。RAID 2.0的思路就是，在做RAID前先切⼏⼑，把西⽠（别打了，玩游戏玩多了不⾏吗），哦，是硬盘切成很多的相等⼤块（Chuck），然后以Chunk为单位来做RAID 5(形成CKG)，然后再把CKG切成更⼩的⼩块（Extent），随机或者按照⼀定规则抽取很多的Extend组成LUN，映射给主机。
选所有个硬盘—》全部切成做⼤块Chuck—》以Chuck为单位做成RAID 5（CKG)—》把CKG切分为相等的⼩块Extend—》选择Extend组成LUN，映射给主机（这个就是RAID 2.0)
RAID 2.0由于RIAD的单位是⼤块Chunk，因此当⼀个硬盘故障，和这个硬盘相关的MINI RAID组（CKG)牵涉的硬盘都参与重组，同样的数据量，⼲活的⼈多了，肯定就快了。这就是RAID 2.0的本质。
⼀句话，如果基于硬盘来做RAID，就是RAID 1.0，如果基于硬盘的⼤块Chunk来做RAID，就是RAID 2.0。
⾄于IBM XIV，他不做RAID，把所有硬盘全部切为1MB⼤⼩，利⽤伪随机算法在不同的节点间保留2个拷贝（有点像RAID 10），因此硬盘故障恢复时间和性能和RAID 2.0是⼀样的，只是容量利⽤率最多只有50%，因此我们就称为\"RAID 2.0-\"把。⾄于华为为什么叫\"RAID 2.0+\据说是基于RAID 2.0上有很多增值的功能，也不知道我的解释是否正确。当然，华为的RAID 2.0⽐3PAR的切的硬盘⼤块Chunk更⼩，因此灵活性和随机分布性更好些。化腐朽为神奇，千⾔万语道不尽RAID 2.0 继续分享RAID 2.0细节的东西
块虚拟化和和LUN虚拟化：这两个术语⼤家可能听说过，⼀般来说，块虚拟化就是指RAID 2.0这样的技术，⽽LUN虚拟化就是指昨天我们说的传统⼚商的RAID1.5改良技术；
和上层应⽤的相关性：RAID技术其实和⽬前流⾏的⾃动分层存储和⾃动精简配置关系最⼤。我们来看⼀下HW HVS的RAID 2.0实现：
这是华为HVS实现的RAID 2.0全景图。⼤家发现没有，⽐我们昨天说的RAID 2.0⼜多切了⼀⼑Grain（⾕粒），这个我们不妨叫为微⼑Grain。经过我对⽐分析总结，我发现RAID 2.0是硬盘拿到后，先⽤⼤⼑切成CHUNK，HW HVS是64M，⽽3PAR 10000是1G，这个CHUNK就是构成RAID的基础；第⼆步就是⽤⼩⼑切成⼩块EXTEND，HW HVS最⼩可以做到256K，⽽3PAR 10000只能做到128M，这个EXTEND是分层存储检测和迁移的单位；最后要切⼀⼑就是⽤⼔⾸切成Grain（⾕粒⼀样细），HW HVS最⼩可以做到8K，⽽3PAR 10000是16K，这个是精简配置分配的单位。当然，不是每个LUN都需要做⾃动精简配置，因此如果是THICK LUN，也有叫FAT LUN，这⼀⼑就不⽤挨了。从这个分析⼤家就可以看出，RAID 2.0确实是软件功能基础的基础，有了这个基础，上⾯的各种软件功能才能更加⾼效和快速。类似EMC/IBM/HDS在传统RAID基础上改进的RAID 1.5，虽然能够实现类似的功能，但在资源的利⽤率和效率、灵活性等等就差很多。有些功能就不能在THIN LUN上⾯做或者只能在THIN LUN上⾯做，THIN的时候必须预留空间，不能像RAID 2.0⼀样按需实时分配。华为HVS对3PAR 10000的改进：这两天很多⼈问这个问题，我也说⼀下我的理解。华为居然敢叫RAID 2.0+，这个”+“可不是⽩加上去的。
⾸先是更细的粒度。上⾯的分析⼤家也看到了，华为的3⼑切的粒度都⽐3PAR的⼩。CHUNK粒度⼩的好处是重构的数据量⽐较少，因为分配数据的时候可以知道那个CHUNK没有数据，不⽤重构，粒度⼩总数据量就少，⽐如只有64M数据的时候，华为只需要重构⼀个64M的CHUNK，但3PAR需要重构⼀个1G的
CHUNK，数据差别还是⽐较⼤的。EXTEND粒度⼩在做热点数据监测和迁移的时候更加准确和⾼效，EXTEND过⼤可能把冷数据也迁移到SSD了，浪费容量。GRAIN粒度过⼤和过⼩都不合适，要和应⽤匹配效率最⾼。但⼤家知道ORACLE常⽤8K作为I/O单位，因此HW针对ORACLE这种场景应该⽐3PAR有更好的THIN效率和性能；
第⼆是华为的块标签技术，这个好像3PAR没有。华为RAID 2.0能够把盘切为⽚后，再把每个⽚打上⼀个标签(TAG)，标签标明此⽚的容量、性能、成本等QoS属性，据此也就⾃然⽽然地使得HVS具备了⾯向不同业务、不同主机、不同应⽤提供不同SLA响应等级的能⼒。这才是RAID 2.0+中”+“的含义，这也是昨天HW的⼀位⾼⼈微信回复我才知道的。
从我的分享⼤家可能发现，RIAD 2.0还是很神奇的，特别是RAID 2.0+，学起来真是⼀个头⼋个⼤。希望我这两个的分享让你成为RAID 2.0⾼⼿。但我昨天总结的⼀句话还是对的：针对物理磁盘做RAID就是传统的RAID 1.0，针对硬盘切⽚CHUNK做RAID就是RAID 2.0。
总的来说，⼤家都认可区分RAID 2.0和RAID 1.0的区别，也就是说，基于硬盘切⽚CHUNK来创建RAID，这个就是RAID 2.0；基于物理硬盘来创建RAID组，这个就是传统的RAID。这个区别可能不是根本的，但可以帮助⼤家理解和辨别。
还有很多⼈混淆CHUNK，Extent，Grain的关系，不知道后⾯再切⼏⼑有啥⽤。我分析3PAR和HW的实现，这⾥再给⼤家解释⼀下。
CHUNK是创建RAID的单位，它的主要作⽤就是⽤来创建RAID组（CKG）。CKG是有属性的，可以是RAID 5，RAID 1，RAID 6啦。我查阅各种⽂档，3PAR⾼端的CHUNK(它叫CHUNKLET)粒度是1GB，⽽中端的粒度是256MB(今天微信公众号“⾼端存储知识”的订阅量也是这个数，哈)。⽽HW HVS是64MB。3PAR没有看到说可以⽤户可以调整这个数值，HW的我不清楚。按照我的理解，这个CHUNK和应⽤关系不⼤，⼀般都⽆需调整（估计⼚商要调整也是底层命令⾏来做，⽤户应该轻易不会去调整这个值的），就像切⽠器，每台阵列选好了⼀个切⽠器，规格就定下来了，所有的西⽠，哦不对是硬盘都切成⼀样的⼤⼩。当然，CHUNK也是硬盘失效重构的最⼩单位。
⾄于Extent，这个⼀个可变的值。也就是⽤户要在上⾯创建LUN，映射给某个主机。主机不同的应⽤可能有不同的要求，如ORACLE，这个块可以⼩些，如对视频数据，这个块可以⼤些。我们以后说的分层存储都是基于这个粒度，系统会检查每个Extent的I/O情况，然后把热数据迁移到SSD上，提升性能。
⽽Grain，这就不是必须的。如果这个LUN是Thin LUN，这⼀⼑⼀般就是要挨的。挨着⼀⼑就是和应⽤每次I/O平均分配的数据量有关，如果匹配，那么分配的效率是最⾼的。我详细分析了3PAR的⽂档，它系统后端设计的每个I/O是16K，因此，它理论上最⼩只能到16K了。
总结⼀下切西⽠⼑法：切⽠器是随⾼端阵列赠送的，因此规格就固定了。但⽤户⾃⼰要想吃西⽠，估计还得拿把西⽠⼑再切分成Extent，男同胞嘴⼤，喜欢切⼤块吃，向我这样的樱桃⼩⼝（喂，⼜别扔臭鸡蛋，再扔，我⼀⼝⼀个臭鸡蛋....)，我喜欢切⼩⼀些。如果家有BB，⽐较瘦⼩（thin），那么还需要⽤⼔⾸再切成颗粒状Grain，⽤⽛签去喂他。当然，不同的BB要求⽽已不同。哎，不说了，⼝⽔都流了⼀地了。我们再来回答⼤家的⼏个问题：CHUNK\\Extent\\Grain的粒度越⼩越好吗？这个有技术门槛吗？
答：不是的。前⾯的分析也可以看到，后⾯两⼑的粒度和应⽤密切相关，也是⽤户创建LUN的时候可以选择调整的，⽽CHUNK主要和RAID的管理和重构有关联，⼩的好处我昨天也提了。但我想事务总是有两⾯性的，太⼩，管理的开销必然⼤，我个⼈设想3PAR把⾼端的CHUNK定义得⽐中端⼤，就是由于⾼端要⽀持的硬盘更多，但3PAR⽬前⾼端的CPU还是⽼⼀代的CPU，中端的CPU已经更新了。还有就是3PAR的内存⽐HW HVS要少。这是我的猜想。这些粒度都没有太多的技术门槛，应该是每个⼚商根据⾃⼰的硬件资源和软件的算法选择的⼀个最优值⽽已；华为HVS真的⽐3PAR好？3PAR真的不⽀持每个块打标签吗？
答：这个昨天我收到最多鸡蛋的地⽅，⼤家都说我有倾向。⽼实说，我也不知道3PAR是否⽀持块打标签，但3PAR有元数据，也会记录这些块的属性，这是必须的，因为后⾯你要做RAID，要做分层，你必须知道这些块是SSD，还是SATA，在那个框⾥等等。只是HW做⽹络出⾝的，⽽且是后做的，是否把MPLS那套思路拿来，标签的属性更加丰富，说不定还可以嵌套，哈哈。总的来说，光从RAID 2.0的对⽐看，HW HVS毕竟是后来者，因此在粒度⽅⾯做得更灵活（⾄于实际的⽤处有多⼤，就是仁者见仁智者见智的事情了），⽽3PAR的优势应该在ASIC上，它的RAID⽤ASIC做的，理论上速度会更快（因此也叫Fast
RAID），3PAR曾经和ORACLE以前做过⼀个测试，它的FAST RAID 5的性能可以做到基本和RAID 10持平（91%），3PAR经常⽤来告诉⽤户，⽤RAID 5就可以了，性能差不多，还省空间。但HW HVS虽然没有ASIC做RAID加速，但毕竟是后发布的产品，可以利⽤更新的平台和更快的CPU，因此整体上性能如何我暂时没有拿到对⽐结果。⾄于应⽤层的功能差别，以后我们再谈。HVS到底是啥缩写？
有知情⼈⼠告诉我，HVS缩写是hyper virtual storage，不再是荣耀。很抱歉，百度上搜索hyper virtual storage，看不到和HVS相关的结果。再次说明华为的宣传是不够的。还有RAID 2.0+这个名字，感觉有点俗⽓，主要是搜索不好搜，这个⼩数点和+号⼀般都被搜索引擎过滤掉了，反正相关的⽂章也不多，如果叫UltraRAID，这种专业名称就⽐较容易宣传了。
RAID 2.0提升了性能和效率，可靠性如何？重构速度真的⽐传统RAID快20倍？ 通过上述⼤家应该基本掌握了RAID 2.0的原理。现在我们就来聊聊RAID 2.0的可靠性问题。 可靠性是⼀个⾮常复杂的问题，我不是这⽅⾯的专家，我只是从我收集的资料整理⼀下分享给⼤家。 可靠性和性能也经常是⽭盾的，作为⽤户，有时需要平衡，这个是⼀个艺术问题，哈，你别不信，看完我今天的分析，估计你也有同感。 我们先从理论上分析⼀下RAID 2.0的可靠性。 ⼤家知道，系统的可靠性=MTBF / ( MTBF + MTTR ) * 100% RAID 2.0(3PAR叫FAST RAID)，通过把数据分散到更多的磁盘，重构时间缩短，MTTR应该⼤⼤缩⼩了。但有⼀个问题，就是针对某⼀个LUN来说，由于数据分散到更多的盘，因此数据丢失的风险⼤⼤提⾼，即MTBF变⼤了。⽐如我采⽤传统的RAID 5（3+1），4个盘同时坏两个的概率是很⼩的，但如果⽤RAID 2.0, 假设这些数据分散到100个盘上，100个盘同时坏2个盘的概率⼤多了。虽然重构速度很快，但双盘失效的概率也提⾼了。那么到底重构减低的风险是否能够平衡掉双盘失效带来的风险呢？（什么，你⼀直想问这个问题，说明你⼊道了，很多童鞋是问不出这个问题来的。对RAID不了解的可以找度娘补习⼀下。⽼实说，我刚学习RAID 2.0的时候第⼀个问题就是这个，问了很多⼈，今天还未能完全解决）。 Markov模型是经典的可靠性预计模型，采⽤Markov模型可以根据系统当前状态及转移条件，来预计系统的可靠性指标。 马尔科夫是俄罗斯著名的数学家，计算公式复杂（我很佩服数学家，这么复杂的计算怎么算出来的），我想⼤家和我⼀样都是俗⼈，不会⾃⼰去算了，对吧。好，我从⾮官⽅渠道拿到⼀份可靠性技术的⽩⽪书，在这⾥第⼀时间分享给⼤家计算结果： 我来解读⼀下这个结果。这个结果说明，从理论上来说，RAID 2.0系统⽐RAID 1.0系统丢失数据的风险要⼩很多。但是别急，这个是对整个系统来说的。也就是说，针对这个⾼端阵列的管理员，他觉得不错，整个系统的可靠性提⾼了。但针对这个⾼端阵列的某个最终⽤户（⽐如ERP系统这个应⽤的IT⼈员帅锅⼩L）来说，好像不是这么回事。⼩L只关⼼ERP的数据，原来采⽤RAID 1.0，数据存放在5块盘上，同时坏两块盘的概率⽐地震都⼩，现在你把⼩L的数据均衡分布到100块盘上了，⼩L他晚上能睡着吗？ 我也在寻求这个答案，⾕歌和度娘都找不到答案。有可靠性专家和我说，其实，这种情况下RAID 2.0的可靠性并不⽐RAID 1.0有优势，对于传统RAID和RAID2.0，发⽣数据丢失的概率和丢失的数据量均近似有“随着系统盘数和硬盘容量的增加⽽成⽐例增⼤”（因此，性能够⽤就好，西⽠池也不要搞太⼤了）。虽然出现故障丢失的数据量要⽐RAID 1.0少，这对⽂件系统和归档来说问题不⼤，但对于数据库来说，丢⼀点都不⾏。因此，重构速度虽然快了，半⼩时搞定，但万⼀半⼩时内再坏第⼆块盘怎么办？⽤RAID 10或者RAID 6，或者做容灾。对头，可靠性要匹配你的需求，这个世界上没有完全可靠的东西，包括爱情，哈。 注意：上⾯的分析没有考虑RAID 1.0重构负载重可能导致的加快硬盘过劳死的风险，因为这个没法算。 RAID 10和RAID 6哪个更可靠？ ⼤家知道，RAID 6最多可以坏任意两块盘数据不丢失，RAID 10可能坏⼀半的盘数据也可能不会丢失。那个的可靠性⾼？我估计80%以上的⼈认为是RAID 10可靠，如果你也是这么认为的，请马上回复微信告诉我，我看看我的判断对不对。其实我也和你们⼀样，我⼀直认为RAID 10更可靠，直到某天⼀个可靠性专家给我⼀份材料，IBM的红⽪书，圣经啊。在IBM的⼀本DS5000的红⽪书⾥，IBM经过计算，结论就是RAID 6的可靠性最⾼，其次才是RAID 10，最差是RAID 5。 但你知道为什么现在⽆数的数据库都推荐⽤RAID 10了吗？因为性能。RAID 10的读写性能好很多。我说性能和可靠性的平衡是⼀个艺术，这回你相信了吧？ ⽹上⼀直有传说说IBM XIV容易丢数据，我⼀直不信，现在想想，信了。为什么呢？它全部⽤SATA盘（现在它也叫SAS盘，其实是假的，是NL-SAS，也就是SAS接⼝，SATA的盘体），采⽤伪随机算法把数据以1M⼤⼩的CHUNK平均分布到所有的磁盘上。SATA盘的可靠性本来就⽐较差，你分布到180块盘，就算你重构速度块，同时坏2块盘必然会造成数据丢失（因为肯定有某1个CHUNK就在这两块盘上）。 对于RAID 2.0来说，已经好多了，RAID可以选择RAID 6。对于传统的⾼端阵列⼚商IBM DS8000/EMC/HDS，他们由于历史原因，底层代码不能变，还是⽤传统的RAID，但为了实现⾃动分层和性能不变，必须要直接切第⼆⼑Extend，对不对? 但在这种RAID 1.5的改良对可靠性更加是个噩梦，我们来欣赏⼀下IBM DS8000的红⽪书⾥⾯的描述： 看到没有，由于DS8000的第⼆到必须在存储池⾥⾯切，⽽这个存储池底层是由多个传统的RAID组（RANK）组成，因此，如果⼀个RAID组失效，⼀个
池的数据都丢失了。因此，你害怕丢失，请容灾。为了控制这个，我记得DS8000⼀个pool下最多放4个RAID组，⽽HDS直接建议⽤RAID 6。你看看，RAID 1.5限制是否很多，RAID 2.0真正从底层解决这些问题就好多了。再⼀次说明，可靠性和性能功能的平衡，真是⼀个艺术活。 最后，我们再谈⼀下重构时间。 先说⼀下我收集到的各个⼚商宣传的数据： HW：1TB重构时间30分钟，⽐传统RAID需要10个⼩时快20倍； IBM XIV：1TB重构时间30分钟； 3PAR：在⽼的胶⽚上写的是重构速度快2倍； 我喜欢刨根问底，我们来分析⼀下：⼤家知道，7200RPM的SATA盘写的带宽⼤约115MB/s，因此，如果采⽤RAID 1.0，理论上需要2.5⼩时写1TB的数据。因为重构的时候只能写⼀个热备盘，这是瓶颈。但⼀般的系统都是有负载的，重构的优先级⼀般都是最低的，因为⽤户要保证业务的运⾏，因此，⼀般的重构时间基本都是理论时间的2-5倍。因此，如果RAID 2.0参与的盘很多，那个30分钟是可以达到的。⽽如果传统的RAID 1.0有较⾼的负载，重构需要10个⼩时也是正常的。因此，HW的宣传虽然稍微有点夸⼤，但基本属实。最关键就是RAID 2.0重构的时候对业务基本没有影响，因为没有热点盘。⽽RAID 1.0重构，对业务的影响是巨⼤的，反过来也影响到重构的速度。 这个⽤户分享了采⽤3PAR的fast RAID，SATA盘重构时间只化了4分钟（这个发挥了RAID 2.0的最⼤好处，只重构⽤过的CHUNK，⽽不⽤整盘重构，估计数据量⽐较⼩），⽽原来采⽤⽼的阵列，重构时间是24⼩时（SATA盘）和4-6⼩时（FC盘）。我也看到另外⼀个⽤户说说他采⽤3PAR的阵列，重构750GB的数据⽤了3个⼩时（业务负载特别重），不过对业务性能没有任何影响（怪不到3PAR宣称它是唯⼀⼀个可以在业务期间换盘的⾼端存储⼚商，不过现在HW HVS把它的唯⼀去掉了，呵呵）。这说明重构时间也是⼀个艺术活，和数据量和业务负载，硬件特性等等都有关系。 最后分享⼀个我想了很长时间才想明⽩的事情，为什么RAID 2.0的重构的总数据量少？RAID 1.0也不是全盘重构的啊？（我估计你们肯定也想不明⽩）。后来在我上周苦练切西⽠⼑法后恍然⼤悟，RAID 1.0能够感知的是LUN，也就是说，从⼀个RAID组⾥划分出LUN后，虽然主机还没有写任何东西，但是系统不知道，因此重构的时候都重构了，⼀般阵列初始化的时候，肯定把LUN都划了，因此相当于整盘重构了。但RAID 2.0划分为CHUNK，每个CHUNK上都有标签，没有分配的CHUNK，或者分配了没有被写过的CHUNK系统都清楚，当然只会重构有数据的CHUNK了，⽽不是整个LUN。 最后问⼤家⼀个问题，采⽤哪种RAID级别，RAID 2.0相⽐RAID 1.0重构时间提升最⼤？哈哈，RAID 10。假设不考虑做奇偶校验的时间，所有的RAID 1.0的重构时间是⼀样的，因为只能同时写1块热备盘，瓶颈在热备盘上。但采⽤RAID 2.0后，瓶颈不在写盘上了，RAID 5和RAID 6多了很多读数据的动作，⽽RAID 10就不⽤了，因此重构的速度提升是最明显的。 通过这些分析，⼤家估计得出的结论和我⼀样，RAID 2.0确实是⼀个颠覆性的技术，优点很多，⽽且有出⾊的性能和不逊于传统RAID的可靠性（带来业务的灵活性我们后⾯还会谈到），并且业界采⽤了⼗⼏年（3PAR 1999年就⽤了），应该是⼀个经过市场检验的RAID⽅法，应该也是⾼端存储以后的发展⽅向。
因篇幅问题不能全部显示，请点此查看更多更全内容