RAID-5（八）失效处理

这些文章已经写了好几年了，可能已经过时了。在MSN space和QQzone几经辗转之后，我想也许这些技术文章还是放在搞技术的博客中更能帮助人。于是做了一个艰难的决定，把这些文章一篇篇搬过来！绝对是原创的。

 

所谓失效（failed），我这里指的是RAID-5下层设备无法正常工作。比方说，下层的n个设备中有两个设备发生了故障，那么在这两个设备上的数据将无法再读写，因为你无法直接读取盘上的数据，也无法通过Parity将这些数据计算出来，同时，写的时候也无法提供足够数据来计算Parity。也就是说，RAID-5已经无法正常工作。

至于是怎样导致失效的？正如前面错误处理中提到，发生了不可修复的I/O错误，导致了RAID-5中的某些rdev无法继续工作。RAID-5的优势就是能容忍一个下层设备出错，讲到这里这个概念应该已经在你的脑中有了深刻的烙印，否则你还是不要再看了。
那我们来看看RAID-5在有设备失效的情况下是怎样处理的。相应代码在handle_stripe中都能找得到。先看看只有一个下层设备失效的情况。

首先是读请求的处理，如果要读的内容是在失效的设备上（请注意在BSR中修复中的dev也被算在了failed设备的行列，虽然它并没有被标记为 Faulty），那么只要这个dev是Empty的，就必须让同stripe的其它dev是Uptodate的，这样就可以利用其它的dev来算出所需的内容。所以其它dev只要是Empty的，就要发起读请求。如果其它的dev都是Uptodate的了，就可以计算出失效盘上的数据。计算完毕，这个dev就是Clean的了，相应的读请求就可以copy数据并返回了。

再来看看写请求的处理。事实上，失效设备对写操作的影响并不大，因为无论rmw还是rcw，只要能把数据copy到dev缓冲区，计算完Parity就可以了，如果设备失效了，只不过不把dev中的数据写到失效的设备中而已。那么失效设备对写请求的影响主要是对预读的影响。通常来讲无论是rcw或者是 rmw，都不得不预读某些数据，除非要写的内容完全覆盖的所有的数据dev，这在我讨论延迟写的时候有提到（当然，如果某些dev上数据已经是Uptodate的了，自然也不用预读）。如果rmw要预读的数据在失效的设备上，那么再作rmw是不划算的，因为为了计算失效设备上的数据又不得不读其它盘上所有的数据。同理rcw要预读的数据在失效的设备上，再作rcw也是不划算的。这时我们通过将预读次数设为 2*disks（设备数的2倍）来退出竞争。当然如果二者最后都要退出，那rcw将作为最后的选择。实际上，有一种情况我们可以直接作出预读判断而不用去计算预读次数，那就是如果在失效的 dev上有写请求，而且该dev不是Clean的，也不是R5_OVERWRITE的，这也就是说这个dev只能通过计算得出，那就意味着要预读出所有的其它正常dev。所以在handle_stripe函数中在处理to_read的这一段中我们可以看到判断这种情况的代码，这里特别提出这种情况是因为这不是在to_write段中处理的，也不用作延迟写。

目前为止，我们讨论了有一个设备失效的情况，这是RAID-5能容忍的，但是如果有多于一个设备失效（包括BSR要修复的dev），RAID-5将无法再处理相应请求。这时所能做就是向上层返回错误消息了。

下一篇我会对handle_stripe做一个概括:)