linux内核奇遇记之md源代码解读之九阵列raid5同步函数sync_request

linux内核奇遇记之md源代码解读之九阵列raid5同步函数sync_request

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

我们再来回顾一下整个场景：

1）在运行阵列的时候调用md_wakeup_thread唤醒主线程

2）主线程调用md_check_recovery检查同步
3）md_check_recovery函数中检查需要同步调用md_register_thread创建同步线程

4）同步线程调用md_do_sync函数处理同步过程

5）md_do_sync做同步过程的管理，一步步推同步点，记录同步完成点，调用sync_request进行各种阵列级别的同步

6）sync_request做同步数据流的派发工作

对于raid5阵列来说，同步是按struct stripe_head为基本单位进行派发的。打个比方，我们现在要把一个土豆炸成薯片，这时首先要把土豆切成片，再把土豆片放到油锅里炸，炸开了再捞起来装盒。那么md_do_sync的作用就相当于把土豆切片，这个切片的大小也就是STRIPE_SECTORS大小了。sync_request接收到这个土豆片之后不能立即下锅，要用struct stripe_head把它包装一下，这就类似要在土豆片外面刷一层调料。然后再调用handle_stripe进行处理并最终下发到磁盘，这就类似于把土豆片放在锅里油炸加工的过程。最后调用bitmap_cond_end_sync保存同步完成记录，这就类似回收土豆片并盒装。

这里还有一个细节，就是为了周期性保存同步结果，每隔几秒钟都会等待所有同步请求返回再记录下来。这就类似于这个炸土豆的锅很小，一次只能放20片土豆，一开始我们不停的放薯片，等放满20片，我们就停下来直接到所有土豆都熟了然后一次性打捞上来，然后再放20片，重复上面的过程。

理解上以上的处理机制，再看代码就非常容易了。

[cpp]  view plain  copy

1. 4453 static inline sector_t sync_request(struct mddev *mddev, sector_t sector_nr, int *skipped, int go_faster)  
2. 4454 {  
3. 4455         struct r5conf *conf = mddev->private;  
4. 4456         struct stripe_head *sh;  
5. 4457         sector_t max_sector = mddev->dev_sectors;  
6. 4458         sector_t sync_blocks;  
7. 4459         int still_degraded = 0;  
8. 4460         int i;  
9. 4461  
10. 4462         if (sector_nr >= max_sector) {  
11. 4463                 /* just being told to finish up .. nothing much to do */  
12. 4464  
13. 4465                 if (test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery)) {  
14. 4466                         end_reshape(conf);  
15. 4467                         return 0;  
16. 4468                 }  
17. 4469  
18. 4470                 if (mddev->curr_resync < max_sector) /* aborted */  
19. 4471                         bitmap_end_sync(mddev->bitmap, mddev->curr_resync,  
20. 4472                                         &sync_blocks, 1);  
21. 4473                 else /* completed sync */  
22. 4474                         conf->fullsync = 0;  
23. 4475                 bitmap_close_sync(mddev->bitmap);  
24. 4476  
25. 4477                 return 0;  
26. 4478         }  

这一部分是处理同步完成的，同步完成有两种情况，一种是正常完成的，另一种是被中断的。

4462行，同步完成。

4470行，同步中断，通知bitmap最后一次同步是abort

4474行，同步成功完成，更新fullsync为0，fullsync表示阵列要强制完全同步。

4475行，通知bitmap同步完成。

虽然这部分代码是放在函数比较靠前的位置，但是这部分代码是在md_do_sync退出同步循环之后的7521行的sync_request调用到的。接下来这部分才是md_do_sync循环中sync_request会执行到的部分：

[cpp]  view plain  copy

1. 4480         /* Allow raid5_quiesce to complete */  
2. 4481         wait_event(conf->wait_for_overlap, conf->quiesce != 2);  
3. 4482  
4. 4483         if (test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery))  
5. 4484                 return reshape_request(mddev, sector_nr, skipped);  
6. 4485  
7. 4486         /* No need to check resync_max as we never do more than one 
8. 4487          * stripe, and as resync_max will always be on a chunk boundary, 
9. 4488          * if the check in md_do_sync didn't fire, there is no chance 
10. 4489          * of overstepping resync_max here 
11. 4490          */  
12. 4491  
13. 4492         /* if there is too many failed drives and we are trying 
14. 4493          * to resync, then assert that we are finished, because there is 
15. 4494          * nothing we can do. 
16. 4495          */  
17. 4496         if (mddev->degraded >= conf->max_degraded &&  
18. 4497             test_bit(MD_RECOVERY_SYNC, &mddev->recovery)) {  
19. 4498                 sector_t rv = mddev->dev_sectors - sector_nr;  
20. 4499                 *skipped = 1;  
21. 4500                 return rv;  
22. 4501         }  
23. 4502         if (!bitmap_start_sync(mddev->bitmap, sector_nr, &sync_blocks, 1) &&  
24. 4503             !test_bit(MD_RECOVERY_REQUESTED, &mddev->recovery) &&  
25. 4504             !conf->fullsync && sync_blocks >= STRIPE_SECTORS) {  
26. 4505                 /* we can skip this block, and probably more */  
27. 4506                 sync_blocks /= STRIPE_SECTORS;  
28. 4507                 *skipped = 1;  
29. 4508                 return sync_blocks * STRIPE_SECTORS; /* keep things rounded to whole stripes */  
30. 4509         }  
31. 4510  
32. 4511         bitmap_cond_end_sync(mddev->bitmap, sector_nr);  
33. 4512  
34. 4513         sh = get_active_stripe(conf, sector_nr, 0, 1, 0);  
35. 4514         if (sh == NULL) {  
36. 4515                 sh = get_active_stripe(conf, sector_nr, 0, 0, 0);  
37. 4516                 /* make sure we don't swamp the stripe cache if someone else 
38. 4517                  * is trying to get access 
39. 4518                  */  
40. 4519                 schedule_timeout_uninterruptible(1);  
41. 4520         }  
42. 4521         /* Need to check if array will still be degraded after recovery/resync 
43. 4522          * We don't need to check the 'failed' flag as when that gets set, 
44. 4523          * recovery aborts. 
45. 4524          */  
46. 4525         for (i = 0; i < conf->raid_disks; i++)  
47. 4526                 if (conf->disks[i].rdev == NULL)  
48. 4527                         still_degraded = 1;  
49. 4528  
50. 4529         bitmap_start_sync(mddev->bitmap, sector_nr, &sync_blocks, still_degraded);  
51. 4530  
52. 4531         set_bit(STRIPE_SYNC_REQUESTED, &sh->state);  
53. 4532  
54. 4533         handle_stripe(sh);  
55. 4534         release_stripe(sh);  
56. 4535  
57. 4536         return STRIPE_SECTORS;  
58. 4537 }  

4481行，每一个wait_event都有一个同步的故事，wait_event就像是十字路口的红绿灯，没有红绿灯的话两边的车都以匀速前进很快就有悲剧发生。同样在linux内核中也有这样的问题，多个线程非原子地访问同一个资源时，都会发生不可预料的结果。这里的wait_event也是因为有了资源访问冲突，搜索wait_for_overlap发现有两种情况：一是正常读写请求，二是同步请求。即相当于两个写者，或者一个读者一个写者，所以就需要按次序去访问资源。

4492行，太多磁盘fail，同步就没必要进行下去了。

4496行，同步且太多fail盘，同步就是构建数据冗余，如果冗余盘都没了，就没必要玩下去了

4498-4500行，通知同步完成。

4502行，通知bitmap同步开始

4506行，很开心，bitmap说已经同步过了，那就跳过。

4511行，处理20土豆片炸好捞上来的情况

4513行，申请struct stripe_head

4525行，判断阵列是否降级，既然降级了为什么还要同步呢。前面讲过，同步就是构建数据冗余，对于Raid5来说只有一个数据冗余，所以降级了就不用同步了。但是对raid6来说有两份冗余数据，只有一个数据盘fail还可以进行同步，但是不更新bitmap。

4529行，通知bitmap开始同步

4531行，设置struct stripe_head同步标志，handle_stripe根据这个标志进行具体处理

4533行，开始处理具体的数据流，即炸土豆的过程

4536行，返回同步大小为STRIPE_SECTORS。

下一节开始介绍raid5数据流，轰轰烈烈的炸土豆秘方将为大家揭晓。

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