linux内核奇遇记之md源代码解读之十一raid5d

转载请注明出处：http://blog.csdn.net/liumangxiong

正是有了上一篇的读写基础，我们才开始看raid5d的代码。raid5d不是读写的入口，也不是读写处理的地方，只是简简单单的中转站或者叫做交通枢纽。这个枢纽具有制高点的作用，就像美国在新加坡的基地，直接就控制了太平洋和印度洋的交通枢纽。

1. 4626 /*
2. 4627  * This is our raid5 kernel thread.
3. 4628  *
4. 4629  * We scan the hash table for stripes which can be handled now.
5. 4630  * During the scan, completed stripes are saved for us by the interrupt
6. 4631  * handler, so that they will not have to wait for our next wakeup.
7. 4632  */
8. 4633 static void raid5d(struct mddev *mddev)
9. 4634 {
10. 4635         struct r5conf *conf = mddev->private;
11. 4636         int handled;
12. 4637         struct blk_plug plug;
13. 4638
14. 4639         pr_debug("+++ raid5d active\n");
15. 4640
16. 4641         md_check_recovery(mddev);
17. 4642
18. 4643         blk_start_plug(&plug);
19. 4644         handled = 0;
20. 4645         spin_lock_irq(&conf->device_lock);
21. 4646         while (1) {
22. 4647                 struct bio *bio;
23. 4648                 int batch_size;
24. 4649
25. 4650                 if (
26. 4651                     !list_empty(&conf->bitmap_list)) {
27. 4652                         /* Now is a good time to flush some bitmap updates */
28. 4653                         conf->seq_flush++;
29. 4654                         spin_unlock_irq(&conf->device_lock);
30. 4655                         bitmap_unplug(mddev->bitmap);
31. 4656                         spin_lock_irq(&conf->device_lock);
32. 4657                         conf->seq_write = conf->seq_flush;
33. 4658                         activate_bit_delay(conf);
34. 4659                 }

4641行，md_check_recovery这个函数前面看过了，用来检查触发同步

4643行，blk_start_plug和4688行blk_finish_plug是一对，用于合并请求。

4646行，这里为什么要来个大循环呢？刚开始看4629行注释可能有点迷糊，可是看到这个循环就知道原来讲的是这里，4629行注释说我们不必等到下次唤醒raid5线程，可以继续处理stripes，因为可能有stripes已经在中断处理函数里处理完成返回了。

4651行，判断阵列对应的bitmap_list是否为空，如果这个链表不为空则进入分支。bitmap跟条带处理有什么关系呢？这个问题就比较有历史性了。对于raid5阵列来说，最可怕的事情莫过于在写的过程中异常掉电，这就意味阵列不知道哪些数据是一致的，哪些是不一致的？这就是safemode干的事情，用来记录阵列数据是否一致。然而数据不一致导致的代码是全盘同步，这个是raid5最头疼的问题。好了，现在有bitmap了可以解决这个问题啦，太happy啦。那bitmap是如何解决这个问题的呢？bitmap说你写每个条带的时候我都记录一下，写完成就清除一下。如果异常掉电就只要同步掉电时未写完成的条带就可以啦。娃哈哈太happy了！！！但是请别高兴的太早，bitmap也不是一个好侍候的爷，bitmap必须要在写条带之前写完成，这里的写完成就是要Write Through即同步写。这下悲催了，bitmap的写过程太慢了，完全拖垮了raid5的性能。于是有了这个的bitmap_list，raid5说，bitmap老弟你批量写吧，有点类似bio的合并请求。但是这也只能部分弥补bitmap带来的负面性能作用。

4655行，下发bitmap批量写请求。
4657行，更新bitmap批量写请求的序号。

4658行，将等待bitmap写的条带下发。

4660行，看函数名就是激活延迟条带的意思。那么为什么要延迟条带的处理呢？按照块设备常用的手段，延迟处理是为了合并请求，这里也是同样的道理。那么条带什么时候做延迟处理呢？我们跟进raid5_activate_delayed函数：

1. 3691static void raid5_activate_delayed(struct r5conf *conf)
2. 3692{
3. 3693     if (atomic_read(&conf->preread_active_stripes) < IO_THRESHOLD) {
4. 3694          while (!list_empty(&conf->delayed_list)) {
5. 3695               struct list_head *l = conf->delayed_list.next;
6. 3696               struct stripe_head *sh;
7. 3697               sh = list_entry(l, struct stripe_head, lru);
8. 3698               list_del_init(l);
9. 3699               clear_bit(STRIPE_DELAYED, &sh->state);
10. 3700               if (!test_and_set_bit(STRIPE_PREREAD_ACTIVE, &sh->state))
11. 3701                    atomic_inc(&conf->preread_active_stripes);
12. 3702               list_add_tail(&sh->lru, &conf->hold_list);
13. 3703          }
14. 3704     }
15. 3705}

3693行，这里控制预读数量。

3694行，遍历阵列延迟处理链表

3695行，获取阵列延迟处理链表表头

3697行，获取阵列延迟处理链表第一个条带

3698行，从阵列延迟处理链表取出一个条带

3700行，设置预读标志

3702行，添加到预读链表中

条带在什么情况下会加入阵列延迟处理链表呢？我们搜索conf->delayed_list，发现加入的时机是设置了STRIPE_DELAYED标志的条带：

1. 204          if (test_bit(STRIPE_DELAYED, &sh->state) &&
2. 205              !test_bit(STRIPE_PREREAD_ACTIVE, &sh->state))
3. 206               list_add_tail(&sh->lru, &conf->delayed_list);

在什么情况下条带会设置STRIPE_DELAYED标志呢？继续搜索STRIPE_DELAYED标志，这里只抽取了相关代码部分：

这里有两种情况会设置STRIPE_DELAYED，rcw和rmw。不管是rcw还是rmw，都不是满条带写，都需要去磁盘预读，因此在效率上肯定比不上满条带写。所以这里需要延迟处理以合并请求。那么合并请求的流程是怎么样的呢？我们这里根据代码流程简要说明一下：

1）第一次非满条带写过来之后，申请到一个struct stripe_head并加入阵列delayed_list延迟处理

2）第二次写过来并命中前面条带，并将bio加入到同一个struct stripe_head中

3）这时再下发请求就可以减少IO，如果凑到满条带就不需要下发读请求了

当然条带命中还有许多其他情况，只要能命中就能提高速度。

回到raid5d函数中来：

1. 4662                 while ((bio = remove_bio_from_retry(conf))) {
2. 4663                         int ok;
3. 4664                         spin_unlock_irq(&conf->device_lock);
4. 4665                         ok = retry_aligned_read(conf, bio);
5. 4666                         spin_lock_irq(&conf->device_lock);
6. 4667                         if (!ok)
7. 4668                                 break;
8. 4669                         handled++;
9. 4670                 }

这里处理阵列的另外一个链表，就是满条块读重试链表。在raid5阵列中，如果刚好是满条块的IO请求，就可以直接下发到磁盘。但如果此时申请不到struct stripe_head就会加入到满条块读重试链表中，等到struct stripe_head释放的时候唤醒raid5d函数，再重新将满条块读请求下发。

再接着往下看：

1. 4672          batch_size = handle_active_stripes(conf);
2. 4673          if (!batch_size)
3. 4674               break;

handle_active_stripes函数就是我们处理条带的主战场，因为大部分条带的处理都要经过这个函数，我们接着进来看这个函数：

1. 4601#define MAX_STRIPE_BATCH 8
2. 4602static int handle_active_stripes(struct r5conf *conf)
3. 4603{
4. 4604     struct stripe_head *batch[MAX_STRIPE_BATCH], *sh;
5. 4605     int i, batch_size = 0;
6. 4606
7. 4607     while (batch_size < MAX_STRIPE_BATCH &&
8. 4608               (sh = __get_priority_stripe(conf)) != NULL)
9. 4609          batch[batch_size++] = sh;
10. 4610
11. 4611     if (batch_size == 0)
12. 4612          return batch_size;
13. 4613     spin_unlock_irq(&conf->device_lock);
14. 4614
15. 4615     for (i = 0; i < batch_size; i++)
16. 4616          handle_stripe(batch[i]);
17. 4617
18. 4618     cond_resched();
19. 4619
20. 4620     spin_lock_irq(&conf->device_lock);
21. 4621     for (i = 0; i < batch_size; i++)
22. 4622          __release_stripe(conf, batch[i]);
23. 4623     return batch_size;
24. 4624}

这个函数几乎可以一览无余。首先是一个大循环，获取最大MAX_STRIPE_BATCH个条带存放到batch数组，4615行挨个处理这个条带数组，4618行调度一下，4621行条带重新进入阵列链表，然后开始下一轮的处理。

我们进入__get_priority_stripe函数看看，究竟是如何选择条带的。

1. 3966/* __get_priority_stripe - get the next stripe to process
2. 3967 *
3. 3968 * Full stripe writes are allowed to pass preread active stripes up until
4. 3969 * the bypass_threshold is exceeded.  In general the bypass_count
5. 3970 * increments when the handle_list is handled before the hold_list; however, it
6. 3971 * will not be incremented when STRIPE_IO_STARTED is sampled set signifying a
7. 3972 * stripe with in flight i/o.  The bypass_count will be reset when the
8. 3973 * head of the hold_list has changed, i.e. the head was promoted to the
9. 3974 * handle_list.
10. 3975 */

每一个社会都有特权阶段，每一个国家都有贵族，所以条带跟条带还是有不一样的，从函数名我们一眼就看出优先选择特权条带，就跟电影《2012》一样，只有被选上才可以上到诺亚方舟。我们虽然不能像古代帝皇那样翻牌子，但我们仍然有优先选择条带处理的权力。

第一特权是handle_list链表，第二特权是hold_list链表。

1. 3976static struct stripe_head *__get_priority_stripe(struct r5conf *conf)
2. 3977{
3. 3978     struct stripe_head *sh;
4. 3979
5. 3980     pr_debug("%s: handle: %s hold: %s full_writes: %d bypass_count: %d\n",
6. 3981            __func__,
7. 3982            list_empty(&conf->handle_list) ? "empty" : "busy",
8. 3983            list_empty(&conf->hold_list) ? "empty" : "busy",
9. 3984            atomic_read(&conf->pending_full_writes), conf->bypass_count);
10. 3985
11. 3986     if (!list_empty(&conf->handle_list)) {
12. 3987          sh = list_entry(conf->handle_list.next, typeof(*sh), lru);
13. 3988
14. 3989          if (list_empty(&conf->hold_list))
15. 3990               conf->bypass_count = 0;
16. 3991          else if (!test_bit(STRIPE_IO_STARTED, &sh->state)) {
17. 3992               if (conf->hold_list.next == conf->last_hold)
18. 3993                    conf->bypass_count++;
19. 3994               else {
20. 3995                    conf->last_hold = conf->hold_list.next;
21. 3996                    conf->bypass_count -= conf->bypass_threshold;
22. 3997                    if (conf->bypass_count < 0)
23. 3998                         conf->bypass_count = 0;
24. 3999               }
25. 4000          }
26. 4001     } else if (!list_empty(&conf->hold_list) &&
27. 4002             ((conf->bypass_threshold &&
28. 4003               conf->bypass_count > conf->bypass_threshold) ||
29. 4004              atomic_read(&conf->pending_full_writes) == 0)) {
30. 4005          sh = list_entry(conf->hold_list.next,
31. 4006                    typeof(*sh), lru);
32. 4007          conf->bypass_count -= conf->bypass_threshold;
33. 4008          if (conf->bypass_count < 0)
34. 4009               conf->bypass_count = 0;
35. 4010     } else
36. 4011          return NULL;
37. 4012
38. 4013     list_del_init(&sh->lru);
39. 4014     atomic_inc(&sh->count);
40. 4015     BUG_ON(atomic_read(&sh->count) != 1);
41. 4016     return sh;
42. 4017}

3986行，优先选择handle_list链表。

3987行，取出一个条带

3989行，判断hold_list链表是否为空。这里是特权阶级的社会，为什么要去视察下面老百姓是否有吃饱呢？因为linux内核深谙“水能载舟，也能覆舟”的道理，如果把下面老百姓逼得太紧难免会社会不安定，所以到关键时刻还是得开仓放粮。这里统计handle_list连续下发的请求个数，如果达到一定数量则在空闲的时候下发hold_list链表的请求。

3991行，如果不是已经在下发请求

3992行，hold_list在这一段时间内未下发条带

3993行，递增bypass_count计数

3995行，reset last_hold，递减bypass_count

4001行，hold_list非空，bypass_count超过上限或者有满条带写

4005行，返回hold_list链表中条带

4007行，更新bypass_count

这里这么多对bypass_count的处理，简单小结一下bypass_count的作用：

1）从handle_list取条带处理，递增bypass_count

2）如果handle_list为空，则判断bypass_count是否达到bypass_threshold，如果是则可以从hold_list取出一个条带来处理，bypass_count减去bypass_threshold

bypass_count就是用来限制低效率preread的下发速度的，增加IO合并机会。

接着看raid5d函数：

1. 4675          handled += batch_size;
2. 4676
3. 4677          if (mddev->flags & ~(1<<MD_CHANGE_PENDING)) {
4. 4678               spin_unlock_irq(&conf->device_lock);
5. 4679               md_check_recovery(mddev);
6. 4680               spin_lock_irq(&conf->device_lock);
7. 4681          }
8. 4682     }

4675行，统计处理条带数

4677行，阵列有变化，则释放设备锁，进行同步检查

raid5d函数也就这样了，每个条带从申请到释放至少要到raid5d走一趟，raid5d迎来一批新条带，又会送走一批条带，每个条带都只是匆匆的过客。

raid5d的介绍就到此，下一小节接着讲raid5的读写流程。