RAID-5（四）make_request

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

 

make_request是RAID-5数据路径的源头，正如我们前面对读写简单叙述中提到的，make_request就是取出stripe_head并将bio插入相应的dev链表，最后对stripe_head做第一轮处理。但我们看make_request的代码，并不是就这么简单的，它还有一些特殊的情况需要处理。

 
首先，对某一个bio上述的过程被一个循环包装起来。这个循环有何作用？如果你对比一下2.4和2.6中make_request的代码，会发现2.4中的make_request并没有这个循环。在2.6中，之所以需要这个循环，是因为bio的大小不再像2.4中的bh那样受到4K的限制了。但是RAID-5的stripe宽度为4K（STRIPE_SIZE），也就是说，一个bio有可能需要插入多个stripe_head中或者同一个stripe的多个dev中。所以，这个循环的作用就是将bio插入它所覆盖的所有stripe_head的dev中。我们可以看作是将bio分成了好几段，并用bio->bi_phys_segments来记下段数。那么，每插到一个dev中，bi_phys_segments++;而每一个dev完成相应的请求，bio退出dev时，bi_phys_segments--，一旦减到0,说明此bio的各段请求都完成，于是整个bio可以返回给上层。这里有点特别的是在进入循环之前,bio->bi_phys_segments初始化为1，而在make_request返回之前又作了一次减1。我认为这里主要是为了处理read-ahead，因为只有read-ahead可能从循环中break出来，如果bio->bi_phys_segments减到0，则直接返回失败。

 
接下来，在make_request中调用的一个很重要的函数是get_active_stripe。它之所以重要是由于stripe_head的数量是有限的，get_active_stripe就是保证有限的stripe_head能有效工作的重要一环。这个函数的详情我打算到后面介绍stripe_head管理中论述。  

在make_request中另一个不可忽视的函数就是add_stripe_bio了。这里我先忽略掉firstwrite和bitmap相关的东西，那么add_stripe_bio所做的第一件事情就是检查新加入的bio是否与现有的bio有区域重叠(overlap)。说实话，我还不是很明白具体在什么情况下能产生这样的重叠，但无论如何RAID-5中是无法同时处理这样的两的bio。于是add_stripe_bio一检查到重叠则立即将dev标记为R5_Overlap并返回。在这种情况下，make_request就会催促原有bio的处理（通过raid5_unplug_device）然后释放已经拿到手的sh，剩下的就是等待原有bio完成（放入wait_for_overlap等待队列）。如果没有出现重叠，或者重叠已经消除，那么bio就会被加入到合适的dev链表中。对于写请求，add_stripe_bio还要做一个特殊的检查，那就是这个bio的写区域是否覆盖了整个dev区域。如果是的话，这个dev就会被打上R5_OVERWRITE标记。R5_OVERWRITE标记在后面的处理sh中会经常碰到，这里我可以稍微提一提它的作用。到目前为止我们已经知道RAID-5处理是以stripe为单位的，计算Parity也是以page为处理单位，那么如果我们的写bio没有覆盖整dev页，某些情况下（具体情况会在下面分析）就不得不先将下层设备中数据读入dev页，才能将bio的数据写入dev页，这样dev页中的数据才能被用来计算新的Parity。怎么样？脑子如果还没乱，congratulations!! 如果取到了stripe_head并加入了bio，第一轮handle_stripe都会在make_request中执行。Handle_stripe完成后，make_request的任务也就完成了。

 

对于写请求，之前我们已经提到过rmw和rcw，请看下集：）。