RAID-5（九）handle_stripe

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

 

通过前面论述的一些RAID-5的数据路径中的一些处理，大家应该已经发现，无论是读还是写都离不开一个函数，handle_stripe。这个函数就像RAID-5数据处理的核心。前面我们所讲的一些操作如rmw和rcw，BSR，延迟写大部分的相关代码都能在handle_stripe中找到。这个函数有近500行的代码，可见这个函数要处理的内容有多么丰富，弄懂了这个函数，基本上就能理解linux中RAID-5数据是如何处理的。

 
实际上前面的论述，已经对handle_stripe的很多处理进行了解析，所以这里我只想对整个handle_stripe串起来再看一遍。  
Handle_stripe的一开始是一个循环，这个循环中做了两件事情，其一就是返回一些读请求，另一个就是为下面的处理统计一些数据。返回读的条件很简单，那就是只要dev的 R5_Uptodate标志位被置为1，也就是说dev的状态是Dirty或者Clean就行，这表明缓冲区中的数据已经是最新的。至于统计的数据就是后续的处理所需的条件，比如说我们通过统计失效设备的个数来决定是否可以恢复一些数据或不得不放弃。

 
Handle_stripe的第二个部分就是处理失效设备个数大于1（包括了BSR中readerror的设备）的情况，在这种情况下所有的读写请求就只能返回处理失败。  

第三个部分就是返回某些写请求，写请求能返回的条件很简单，就是首先看Parity是否已经写到磁盘上，然后再看写入数据的dev是否已经是Clean的。  

接下来的一个部分就是看是否需要向下层读取数据。这里处理的读取主要是3类，一个是上层的读请求，一个是上层的写请求没有覆盖整个缓冲区，还有一个是跟 resync和recovery有关，这需要读取所有dev的数据。至于为什么没有把写请求的读放在写预读中处理，我的理解是因为这种情况是必须要读的， 是不可能通过rmw或rcw或者延迟写的方式来避免的。在这一部分有个比较特殊的处理就是如果只有要读数据的dev还是Empty的，其他dev上的数据都是Uptodate的了，我们就不用到下层去读了，而是通过其他dev上的数据计算出来，这种情况可能更多是出在有失效设备的情况下。  

再下一部分就是处理写请求。写请求一开始就是要处理预读，正如以前所述，就是判断是做rmw还是rcw，然后做预读，在预读条件不满足的情况下就进入延迟写状态。等到处理写的一切条件都满足了就可以将数据向下层设备写。  

Handle_stripe还有一部分的内容就是处理resync或recovery的请求，我打算在下面讨论resync和recovery的时候再具体介绍。  

BSR调度被放在了handle_stripe的倒数第二的部分。那么handle_stripe的最后一个部分干了两件事：1.如果有bio可以返回了，调用其bi_end_io回调函数返回上层。2.如果dev上有读写要求，就通过设置其req这个bio结构送到下一层，当然如果下层设备是Faulty或者已经被移除了，那么就清掉R5_Locked标志，不需要做什么其他的操作。

下一篇RAID-5的守护线程raid5d将是讨论的重点:)