linux内核奇遇记之md源代码解读之十一raid5d
linux内核奇遇记之md源代码解读之十一raid5d
转载请注明出处：http://blog.csdn.net/liumangxiong
正是有了上一篇的读写基础，我们才开始看raid5d的代码。raid5d不是读写的入口，也不是读写处理的地方，只是简简单单的中转站或者叫做交通枢纽。这个枢纽具有制高点的作用，就像美国在新加坡的基地，直接就控制了
太平洋和印度洋的交通枢纽。
4626 /*
4627 * This is our raid5 kernel thread.
4628 *
4629 * We scan the hash table for stripes which can be handled now.
4630 * During the scan, completed stripes are saved for us by the interrupt
4631 * handler, so that they will not have to wait for our next wakeup.
4632 */
4633 static void raid5d(struct mddev *mddev)
4634 {
4635 struct r5conf *conf = mddev->private;
4636 int handled;
4637 struct blk_plug plug;
4638
4639 pr_debug("+++ raid5d active\n");
4640
4641 md_check_recovery(mddev);
4642
4643 blk_start_plug(&plug);
4644 handled = 0;
4645 spin_lock_irq(&conf->device_lock);
4646 while (1) {
4647 struct bio *bio;
4648 int batch_size;
4649
4650 if (
4651 !list_empty(&conf->bitmap_list)) {
4652 /* Now is a good time to flush some bitmap updates */
4653 conf->seq_flush++;
4654 spin_unlock_irq(&conf->device_lock);
4655 bitmap_unplug(mddev->bitmap);
4656 spin_lock_irq(&conf->device_lock);
4657 conf->seq_write = conf->seq_flush;
4658 activate_bit_delay(conf);
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批量写请求的序号。
4657行，更新bitmap批量写请求的序号。
4658行，将等待bitmap写的条带下发。
4660 raid5_activate_delayed(conf);
46614660行，看函数名就是激活延迟条带的意思。那么为什么要延迟条带的处理呢？按照块设备常用的手段，延迟处理是为了合并请求，这里也是同样的道理。那么条带什么时候做延迟处理呢？我们跟进raid5_activate_delayed函数：
3691static void raid5_activate_delayed(struct r5conf *conf)
3692{
3693 if (atomic_read(&conf->preread_active_stripes) < IO_THRESHOLD) {
3694 while (!list_empty(&conf->delayed_list)) {
3695 struct list_head *l = conf->delayed_list.next;
3696 struct stripe_head *sh;
3697 sh = list_entry(l, struct stripe_head, lru);
3698 list_del_init(l);
3699 clear_bit(STRIPE_DELAYED, &sh->state);
3700 if (!test_and_set_bit(STRIPE_PREREAD_ACTIVE, &sh->state))
3701 atomic_inc(&conf->preread_active_stripes);
3702 list_add_tail(&sh->lru, &conf->hold_list);
3703 }
3704 }
3705}
3693行，这里控制预读数量。
3694行，遍历阵列延迟处理链表
3695行，获取阵列延迟处理链表表头
3697行，获取阵列延迟处理链表第一个条带
3698行，从阵列延迟处理链表取出一个条带
3700行，设置预读标志
3702行，添加到预读链表中
条带在什么情况下会加入阵列延迟处理链表呢？我们搜索conf->delayed_list，发现加入的时机是设置了STRIPE_DELAYED标志的条带：
204 if (test_bit(STRIPE_DELAYED, &sh->state) &&
205 !test_bit(STRIPE_PREREAD_ACTIVE, &sh->state))
206 list_add_tail(&sh->lru, &conf->delayed_list);
在什么情况下条带会设置STRIPE_DELAYED标志呢？继续搜索STRIPE_DELAYED标志，这里只抽取了相关代码部分：
2772static void handle_stripe_dirtying(struct r5conf *conf,
2773 struct stripe_head *sh,
2774 struct stripe_head_state *s,
2775 int disks)
2776{
...
2808 set_bit(STRIPE_HANDLE, &sh->state);
2809 if (rmw < rcw && rmw > 0)
...
2825 } else {
2826 set_bit(STRIPE_DELAYED, &sh->state);
2827 set_bit(STRIPE_HANDLE, &sh->state);
2828 }
2829 }
2830 }
2831 if (rcw <= rmw && rcw > 0) {
...
2851 } else {
2852 set_bit(STRIPE_DELAYED, &sh->state);
2853 set_bit(STRIPE_HANDLE, &sh->state);
2854 }这里有两种情况会设置STRIPE_DELAYED，rcw和rmw。不管是rcw还是rmw，都不是满条带写，都需要去磁盘预读，因此在效率上肯定比不上满条带写。所以这里需要延迟处理以合并请求。那么合并请求的流程是怎么样的呢？我们这里根据代码流程简要说明一下：
1）第一次非满条带写过来之后，申请到一个struct stripe_head并加入阵列delayed_list延迟处理
2）第二次写过来并命中前面条带，并将bio加入到同一个struct stripe_head中
3）这时再下发请求就可以减少IO，如果凑到满条带就不需要下发读请求了
当然条带命中还有许多其他情况，只要能命中就能提高速度。
回到raid5d函数中来：
4662 while ((bio = remove_bio_from_retry(conf))) {
4663 int ok;
4664 spin_unlock_irq(&conf->device_lock);
4665 ok = retry_aligned_read(conf, bio);
4666 spin_lock_irq(&conf->device_lock);
4667 if (!ok)
4668 break;
4669 handled++;
4670 }
这里处理阵列的另外一个链表，就是满条块读重试链表。在raid5阵列中，如果刚好是满条块的IO请求，就可以直接下发到磁盘。但如果此时申请不到struct stripe_head就会加入到满条块读重试链表中，等到struct stripe_head释放的时候唤醒raid5d函数，再重新将满条块读请求下发。
再接着往下看：
4672 batch_size = handle_active_stripes(conf);
4673 if (!batch_size)
4674 break;
handle_active_stripes函数就是我们处理条带的主战场，因为大部分条带的处理都要经过这个函数，我们接着进来看这个函数：
4601#define MAX_STRIPE_BATCH 8
4602static int handle_active_stripes(struct r5conf *conf)
4603{
4604 struct stripe_head *batch[MAX_STRIPE_BATCH], *sh;
4605 int i, batch_size = 0;
4606
4607 while (batch_size < MAX_STRIPE_BATCH &&
4608 (sh = __get_priority_stripe(conf)) != NULL)
4609 batch[batch_size++] = sh;
4610
4611 if (batch_size == 0)
4612 return batch_size;
4613 spin_unlock_irq(&conf->device_lock);
4614
4615 for (i = 0; i < batch_size; i++)
4616 handle_stripe(batch[i]);
4617
4618 cond_resched();
4619
4620 spin_lock_irq(&conf->device_lock);
4621 for (i = 0; i < batch_size; i++)
4622 __release_stripe(conf, batch[i]);
4623 return batch_size;
4624}
这个函数几乎可以一览无余。首先是一个大循环，获取最大MAX_STRIPE_BATCH个条带存放到batch数组，4615行挨个处理这个条带数组，4618行调度一下，4621行条带重新进入阵列链表，然后开始下一轮的处理。
我们进入__get_priority_stripe函数看看，究竟是如何选择条带的。
3966/* __get_priority_stripe - get the next stripe to process
3967 *
3968 * Full stripe writes are allowed to pass preread active stripes up until
3969 * the bypass_threshold is exceeded. In general the bypass_count
3970 * increments when the handle_list is handled before the hold_list; however, it
3971 * will not be incremented when STRIPE_IO_STARTED is sampled set signifying a
3972 * stripe with in flight i/o. The bypass_count will be reset when the
3973 * head of the hold_list has changed, i.e. the head was promoted to the
3974 * handle_list.
3975 */
每一个社会都有特权阶段，每一个国家都有贵族，所以条带跟条带还是有不一样的，从函数名我们一眼就看出优先选择特权条带，就跟电影《2012》一样，只有被选上才可以上到诺亚方舟。我们虽然不能像古代帝皇那样翻牌子，但我们仍然有优先选择条带处理的权力。
第一特权是handle_list链表，第二特权是hold_list链表。
3976static struct stripe_head *__get_priority_stripe(struct r5conf *conf)
3977{
3978 struct stripe_head *sh;
3979
3980 pr_debug("%s: handle: %s hold: %s full_writes: %d bypass_count: %d\n",
3981 __func__,
3982 list_empty(&conf->handle_list) ? "empty" : "busy",
3983 list_empty(&conf->hold_list) ? "empty" : "busy",
3984 atomic_read(&conf->pending_full_writes), conf->bypass_count);
3985
3986 if (!list_empty(&conf->handle_list)) {
3987 sh = list_entry(conf->handle_list.next, typeof(*sh), lru);
3988
3989 if (list_empty(&conf->hold_list))
3990 conf->bypass_count = 0;
3991 else if (!test_bit(STRIPE_IO_STARTED, &sh->state)) {
3992 if (conf->hold_list.next == conf->last_hold)
3993 conf->bypass_count++;
3994 else {
3995 conf->last_hold = conf->hold_list.next;
3996 conf->bypass_count -= conf->bypass_threshold;
3997 if (conf->bypass_count < 0)
3998 conf->bypass_count = 0;
3999 }
4000 }
4001 } else if (!list_empty(&conf->hold_list) &&
4002 ((conf->bypass_threshold &&
4003 conf->bypass_count > conf->bypass_threshold) ||
4004 atomic_read(&conf->pending_full_writes) == 0)) {
4005 sh = list_entry(conf->hold_list.next,
4006 typeof(*sh), lru);
4007 conf->bypass_count -= conf->bypass_threshold;
4008 if (conf->bypass_count < 0)
4009 conf->bypass_count = 0;
4010 } else
4011 return NULL;
4012
4013 list_del_init(&sh->lru);
4014 atomic_inc(&sh->count);
4015 BUG_ON(atomic_read(&sh->count) != 1);
4016 return sh;
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函数：
4675 handled += batch_size;
4676
4677 if (mddev->flags & ~(1<device_lock);
4679 md_check_recovery(mddev);
4680 spin_lock_irq(&conf->device_lock);
4681 }
4682 }
4675行，统计处理条带数
4677行，阵列有变化，则释放设备锁，进行同步检查
raid5d函数也就这样了，每个条带从申请到释放至少要到raid5d走一趟，raid5d迎来一批新条带，又会送走一批条带，每个条带都只是匆匆的过客。
raid5d的介绍就到此，下一小节接着讲raid5的读写流程。
转载请注明出处：http://blog.csdn.net/liumangxiong