Raid1源代码分析--读流程

  我阅读的代码的linux内核版本是2.6.32.61。刚进实验室什么都不懂,处于摸索阶段,近期的任务就是阅读raid1的源码。第一次接触raid相关的东西,网上分析源码的资料又比较少,不详细。逐行阅读代码,做了笔记。如果要对raid1的读流程有个整体上的把握,需要将笔记中的主线提炼出来,这里不写了。理解不足或者有误之处,希望批评指正。

  读流程主要涉及以下函数:

    请求函数make_request

    读均衡read_balance

    回调函数raid1_end_read_request

    读出错处理raid1d

    尝试修复读出错fix_read_error

  下面具体分析raid1的读流程。

请求函数make_request

  读请求封装成bio后,由md设备的md_make_request下发请求,md又发给具体的设备raid1,对应raid1的make_request函数,下面将从raid1的make_request开始理解该部分的流程。

  1.  如果访问要求设置barrier,而设备不支持设置barrier,则结束bio,立即返回。

  2.  等待设备上的barrier消除。

  注:当md收到一个barrier bio请求时,md会先把在该barrier
bio之前到达的bio完成,然后再完成barrier bio,之后再处理在barrier
bio之后到达的bio。barrier是通过conf->barrier来完成设置。

  这儿的barrier是上一个请求设置的barrier,也就是等待上一个请求处理“结束”,注意此时的“结束”不一定是上一个请求真的完全结束,而有可能设置了behind
write模式,在写完除了非WriteMostly,则通知r1_bio的state为UpToDate(有效的,可以进行后面的请求处理)。

  同步一定会设置barrier,代码中有raise_barrier(conf);该障碍在同步结束后end_sync_write中调用put_buf操作conf->barrier来清除。写请求由用户请求本身决定是否设置barrier。

  3.  申请一个r1_bio结构(该结构主要用于管理raid1的bio),该结构中有一个数组bios数组指向对应各磁盘的bio。

  4.  调用read_balance算法,获取读目标的盘号rdisk。(具体分析见下一节)

  5.
 如果获取的盘号为错误盘号(即-1),表示目前不能获取读目标,那么结束这个bio(调用raid_end_bio_io(r1_bio)),返回。

  6.  通过盘号rdisk和指针数组首地址conf->mirrors得到读目标的mirror_info结构指针mirror。

  7.
 通过mirror->rdev->flags可以知道该磁盘是否设置了WriteMostly属性。如果设置了WriteMostly,则通过bitmap可以知道是否仍然还有延迟写。如果延迟写还没结束,那么等待延迟写结束。其他的情况都不处理,直接往下走。

  8.  将读目标盘号赋值给r1_bio->read_disk。

  9.  将接受到的上层bio(读请求)复制一份,指针read_bio和r1_bio->bios[rdisk]都指向该bio。

  10.设置该read_bio的相关属性,使得符合r1_bio结构的要求,比如读写属性,盘阵上哪个盘,盘的扇区,从而让它能正确下发到下层,最终找到相应的读目标盘;也设置了结束请求函数raid1_end_read_request。

  11.  下发read_bio。

读均衡read_balance

  这个算法是用来做读均衡的,在raid1中涉及到的读操作均会使用到该算法。入口参数为raid1的私有数据结构*conf和raid1管理bio的结构*r1_bio,具体流程分析如下:

  1.  如果盘阵正在进行同步操作,并且访问落在同步窗口中,按照下面的子流程选出盘号。则进入下面的步骤2来处理,否则进入步骤3。

  注:conf->mddev->recovery_cp <
MaxSector,表示盘阵正在同步。代码中MaxSector的值为扇区数量的上限,而conf->mddev->recovery_cp表示正在进行同步的扇区号,所以自然就约定没有进行同步的时候conf->mddev->recovery_cp
= MaxSector。

  扇区号加扇区数等于最后一个要读的扇区+1,如果大于等于下一个要同步的扇区,则说明落在同步窗口之中。

   1.1  从last_used的磁盘开始,循环遍历盘阵中每个盘(2个盘),选出第一个正确的盘。

    1.1.1
 如果盘之前读失败(IO_BLOCKED)(在所有磁盘,都不能读的时候。由于之前为读写状态,所以可能因为写或者同步的原因造成的阻塞),或者盘不存在(之前为只读,但是还是读失败了),或者可能需要同步(In_sync=0),或者是WriteMostly盘,则继续循环。

    1.1.2  如果是WriteMostly盘,则记录下wonly为该盘号。

    1.1.3
 如果所有盘遍历完(其实就是第2块盘)还是没有跳出循环,那么只好将WriteMostly盘的盘号选择出来(如果有的话),或者选出一个错误盘号(wonly的初始值-1)。跳出循环。

   1.2  如果选出的是一个错误盘号,那么直接出错返回。

   1.3  如果选出的盘号是正确的,那么继续下面的流程。

    (选出的盘号记录在new_disk中)

  2.  如果选出盘new_disk的磁头位置正好位于本次操作的起点,那么就直接确定为盘号new_disk。分别有如下两种情况: 

   2.1  一种是上次读均衡算法结束之后就更新了conf->next_seq_sect。

   2.2
 一种是上次成功读写(包括同步读写)完成后,通过pdate_head_pos来更新了conf->mirrors[new_disk].
head_position。

  3.  如果选出盘new_disk的磁头和本次操作的起点不一样。disk作为循环控制的磁盘号,new_disk作为返回的磁盘号。

   3.1  首先将disk--,变成其他盘号,与上次读的盘号不同。(我觉得这里体现均衡)

   3.2
 如果盘之前读失败(IO_BLOCKED)(在所有磁盘,都不能读的时候。由于之前为读写状态,所以可能因为写或者同步的原因造成的阻塞),或者盘不存在(之前为只读,但是还是读失败了),或者可能需要同步(In_sync=0),或者是WriteMostly盘,则继续循环。

   3.3  如果磁盘上无等待的操作,那么确定为该磁盘盘号,跳出循环。

   3.4  如果所有磁盘都有等待操作,那么找到当前磁头位置和本次操作位置最为接近的磁盘盘号。(通过current_distance
和new_distance来控制,current_distance是到目前为止最近的距离,new_distance是最新加入的一个最近距离)

  4.  如果选出盘rdev不存在,那么重新执行read_balance算法。

  5.  递增选出盘rdev的下发IO计数。

  6.
 如果到了这一步发现该盘的rdev->flags的设置In_sync(该盘可能需要同步),递减选出盘rdev的下发IO计数,那么重新执行read_balance算法。

  7.
 设置新的conf->next_seq_sect(下一个顺序读扇区),新的conf->last_used(最近一次使用的磁盘盘号)

  8.  返回选出的磁盘号,即为读均衡磁盘。

回调函数raid1_end_read_request

  1. 如果bio的状态为有效(BIO_UPTODATE),那么设置uptodate为1。

  2. 调用update_head_pos(mirror, r1_bio)更新当前盘的磁头位置。

  3. 如果bio的状态为有效,设置r1_bio的状态也为有效(R1BIO_Uptodate),并调用raid_end_bio_io结束这个bio。

  4. 如果bio的状态不是有效,并且所有盘都处于降级状态,或者只有一个盘处于正常状态但是该盘出错,那么设uptodate为1(这里不是表示状态为有效,而是表示不用retry了),然后调用raid_end_bio_io结束这个bio。

  5. 其他情况则表示读出错了。并将r1_bio放入retry队列,转由守护进程处理。通过reschedule_retry(r1_bio)调用wake_up(&conf->wait_barrier)。

  6. 递减选出盘rdev的下发IO计数。

读出错处理raid1d

  raid1d是守护进程,很多情况都会切换到该进程,而该进程描述了这些不同种情况下的处理流程。先处理激活同步守护进程,再提交pending_bio_list的所有请求,再一个一个的提交retry_list的r1_bio。判断r1_bio->state,如果是R1BIO_IsSync,则转入同步写流程;如果是R1BIO_BarrierRetry,这个情况只发生在写操作,则转入处理barrier的流程;如果是其他情况,则是读出错,进入读失败处理流程。下面分析读出错的处理流程。

  1. 如果md是读写状态。

    1.1  冻结盘阵。调用freeze_array(conf)实现。

      1.1.1  通过barrier计数挡住所有新的I/O。 

      1.1.2  把触发freeze_array的I/O(即失败的readI/O)加到wait计数。

      1.1.3  等待所有已经进入raid1层的I/O完成。

        这里等待的事件是“所有已进入raid1的readI/O挂入retry表,所有已进入raid1的writeI/O完成写动作。”

    1.2  尝试修复读出错。调用fix_read_error()实现。

    1.3  解冻盘阵。调用unfreeze_array(conf)实现。

  2.  如果md是只读状态,那么失效(md_error)读目标盘。

  3.  重新调用读均衡算法,得到一个盘号disk。

  4.  如果返回的盘号仍然为负值,那么表示无法恢复读出错,调用raid_end_bio_io结束这个bio。

  5.  如果返回盘号为正常值,那么根据是否只读,设置原读出错的盘指针为IO_BLOCKED或者NULL。

  6.  设置r1_bio->read_disk为新的读目标盘号disk。

  7.  Put掉原bio,bio_put(bio)。

  8.
 将master_bio复制一份给bio,并用r1_bio->bios[r1_bio->read_disk指向该bio。

  9.  设置该bio,并将回调函数设置为raid1_end_read_request,下发该bio。

  10. cond_resched()如果有进程要抢占,则切换进程;如果不是,则继续循环。

尝试修复读出错fix_read_error

  1. 大循环,判断条件为sectors不为0,进入循环。

  2. 将需要处理的扇区数sectors复制给变量s,将读目标盘号read_disk赋值给d。

  3. 控制s的大小在 PAGE_SIZE>>9 以内。

  4. 从read_disk开始遍历盘阵中的每个盘。找到一个可以读这次page的盘,记录盘号为d,并读出来置于conf->tmppage中,跳出循环;或者没有可以读的盘,跳出循环。

  5. 如果没有可以读的盘,那么失效(md_error)原读目标盘,退出大循环,返回。

  6. 从步骤4中选出d号盘,往回遍历,直到read_disk。将conf->tmppage依次写入这些盘中。如果某次磁盘写入错误,那么失效(md_error)该次写入的磁盘。

  7. 从步骤4中选出d号盘,往回遍历,直到read_disk。将conf->tmppage依次从这些盘中读出。

    7.1  如果某次磁盘写入错误,那么失效(md_error)该次写入的磁盘。

    7.2  如果某次磁盘写入正确,那么该次磁磁盘对该大循环对应的page修复成功。

  8.  判断条件sectors = sectors – s,每次循环的sync_page_io起点标记sect =
sect+1。进入下一个循环。

  raid1还有写流程和同步流程,以后再记录下来。努力让自己尽快入门,加油!

Raid1源代码分析--读流程,布布扣,bubuko.com

时间: 2025-01-01 11:27:48

Raid1源代码分析--读流程的相关文章

Raid1源代码分析--初始化流程

初始化流程代码量比较少,也比较简单.主要是run函数.(我阅读的代码的linux内核版本是2.6.32.61) 四.初始化流程分析 run函数顾名思义,很简单这就是在RAID1开始运行时调用,进行一些初始化的操作.主要是对RAID1中的conf进行初始化.run函数在md.c的do_md_run中被调用.   run函数的具体流程 0.传入参数mddev就是指RAID1所处的MD设备. 1.  定义相关变量. 1.1  定义conf指针,类型为raid1_private_data_s,是raid

Raid1源代码分析--写流程

正确写流程的总体步骤是,raid1接收上层的写bio,申请一个r1_bio结构,将其中的所有bios[]指向该bio.假设盘阵中有N块盘.然后克隆N份上层的bio结构,并分别将每个bios[]指向克隆出来一个bio结构,然后进行相应设置. 对于没有Write Behind模式而言,之后将所有这些bios[](共用页结构)放入队列pending_list中,对内存bitmap置位.接着由守护进程摘取pending_list链中的bio,然后将内存bitmap同步下刷到磁盘,紧接着立即一次性下发bi

Raid1源代码分析--同步流程

同步的大流程是先读,后写.所以是分两个阶段,sync_request完成第一个阶段,sync_request_write完成第二个阶段.第一个阶段由MD发起(md_do_sync),第二个阶段由守护进程发起. 如果是用户发起的同步请求.该请求下发到raid1层,首先进入同步读函数sync_request.在正常的成员盘中,将所有active可用的盘(rdev->flags中有In_sync标记)设置为read盘,而所有不可用的盘不做设置.对每一个可用盘对应的bios[]都单独申请页结构,对所有的

MD中bitmap源代码分析--清除流程

bitmap的清零是由bitmap_daemon_work()来实现的.Raid1守护进程定期执行时调用md_check_recovery,然后md_check_recovery会调用bitmap_daemon_work根据各种状态进行清零的操作.Bitmap_daemon_work的实现比较复杂,bitmap的清理需要两次调用bitmap_daemon_work来完成的.下面主要以图的形式逐步分析bitmap清除的全部过程. 刚进入这个函数的时候内存bitmap file的页bitmap_at

MD中bitmap源代码分析--设置流程

1. 同步/异步刷磁盘 Bitmap文件写磁盘分同步和异步两种: 1) 同步置位:当盘阵有写请求时,对应的bitmap文件相应bit被置位,bitmap内存页被设置了DIRTY标志.而在下发写请求给磁盘之前,必须保证bitmap文件下刷完成后才向磁盘发送写请求.这种情况需要等待写bitmap磁盘文件完成,因此是同步的.(由bitmap_unplug()完成) 之所以写bit要在写chunk数据之前就同步刷磁盘,因为如果写请求先下发了,而写bit在这之后刷磁盘的话,当写磁盘过程中发生故障,比如掉电

nginx源代码分析--读请求主体(1)

首先,读取请求体已进入HTTP要求11相,我们需要做的请求正文部分处理一些模块,所以这个模块需要注册功能在这个阶段,在阅读功能要求的身体ngx_http_read_client_request_body()是存在的.仅仅只是不同的模块可能对请求体做不同的处理.读取请全体的函数是在某个模块的conent_handler函数中包括的.比方比方proxy模块,fastcgi模块,uwsgi模块等这些模块对请求体感兴趣,那么读取请求体的函数在这些模块的content_handler中注冊. 上节说到ng

Monkey源代码分析之执行流程

在<MonkeyRunner源代码分析之与Android设备通讯方式>中.我们谈及到MonkeyRunner控制目标android设备有多种方法.当中之中的一个就是在目标机器启动一个monkey服务来监听指定的一个port,然后monkeyrunner再连接上这个port来发送命令.驱动monkey去完毕对应的工作. 当时我们仅仅分析了monkeyrunner这个client的代码是怎么实现这一点的,但没有谈monkey那边是怎样接受命令,接受到命令又是怎样处理的. 所以自己打开源代码看了一个

openVswitch(OVS)源代码分析之工作流程(数据包处理)

上篇分析到数据包的收发,这篇开始着手分析数据包的处理问题.在openVswitch中数据包的处理是其核心技术,该技术分为三部分来实现:第一.根据skb数据包提取相关信息封装成key值:第二.根据提取到key值和skb数据包进行流表的匹配:第三.根据匹配到的流表做相应的action操作(若没匹配到则调用函数往用户空间传递数据包):其具体的代码实现在 datapath/datapath.c 中的,函数为: void ovs_dp_process_received_packet(struct vpor

【Heritrix源代码分析4】开始一个爬虫抓取的全流程代码分析

在创建一个job后,就要开始job的运行,运行的全流程如下: 1.在界面上启动job 2.index.jsp 查看上述页面对应的源代码 <a href='"+request.getContextPath()+"/console/action.jsp?action=start'>Start</a> 3.action.jsp String sAction = request.getParameter("action"); if(sAction !