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_attr设置为BITMAP_PAGE_CLEAN。

  每次进入bitmap_daemon_work首先判断该函数是否睡够,如果没有睡够,则直接返回。这个睡眠是为了将一定时间见内的写盘操作集中批量处理。为了达到异步刷磁盘的效果,bitmap_daemon_work函数进行两轮才完成bit的清除。

  第一次bitmap_daemon_work()的作用

  1. 将所有的内存bitmap file的页bitmap_attr的属性BITMAP_PAGE_CLEAN清除;
  2. 设置bit所在页属性为BITMAP_PAGE_CLEAN和BITMAP_PAGE_NEEDWRITE;
  3. 处理到的每个bit对应的*bmc值设置为1。

  第二次bitmap_daemon_work()的作用:

  1. 将所有的内存bitmap file的页bitmap_attr属性BITMAP_PAGE_CLEAN清除;
  2. bit对应的*bmc设置为0;
  3. bit逐一清零;
  4. 将bitmap_attr属性BITMAP_PAGE_NEEDWRITE清除;
  5. bitmap对于一个page的bitmap file一次下刷到磁盘。

  不论哪次进入bitmap_daemon_work(),处理流程都是以page为单位来对bitmap file缓存处理,从第一个page逐步处理到最后一个page,作为一个大循环遍历所有的page。在page内部,以每个bit和对应的chunk来处理,从第一个chunk逐步处理到最后一个chunk。

  具体处理流程见下面几幅图所示,注意其中的lastpage的含义可能会有不同,已经在图中标出,需要注意的是每一步的先后顺序,bitmap_attr属性设置、bitmap刷磁盘的时机,每次处理bitmap file的page的不同之处已经用红框标出。

  这种异步清零的机制好处在于,在还未清零或者内存位图清0但没有刷到磁盘的时候,又有对该页的写请求到来,就只用增加bmc计数器或者只是把内存位图置位,而不用再写到外存的位图文件中,从而减少了一次写外存位图的io。另外,bit清零不用急着去做,异步则可以使系统资源转向处理更要紧的进程。

……

……

……

……

……

……

转载请注明出处:http://www.cnblogs.com/fangpei/

时间: 2024-10-19 23:06:10

MD中bitmap源代码分析--清除流程的相关文章

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

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

MD中bitmap源代码分析--入题概述

在MD模块中,各级raid都使用的一份bitmap的源码,也就是说共用一种bitmap的流程,下面以raid1的使用为例来分析bitmap的工作原理. 在使用raid1磁盘阵列的时候,对于数据的可靠性有很高的要求.在写的过程中,有可能存在不稳定的因素,比如磁盘损坏.掉电/宕机.网络故障.系统故障等,这样导致写入失败,在系统恢复后,raid也需要进行恢复,如果磁盘比较大,那同步恢复的过程会很长.以raid1来说,在发生故障时,可能盘阵的数据很多都是已经一致的了,其实只有少部分不一致,所以就没必要进

MD中bitmap源代码分析--状态机实例

1. page_attrs的状态转换关系 之前说过,bitmap的优化核心是:bitmap设置后批量写入:bitmap延时清除.写bit用bitmap_statrwrite() + bitmap_unplug()两个函数,实现了bitmap设置后的批量写入:清bit用bitmap_endwrite()+两轮bitmap_deamon_work()实现了bitmap延迟清除.   2. 一个实例分析 下面以一个写请求实例来进行分析.假设写之前的chunk的数据都是一致的,还是以写3*4096*8(

Raid1源代码分析--读流程

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

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源代码分析--同步流程

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

Raid1源代码分析--写流程

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

IC设计中的功耗分析的流程

首先声明本文所讲的范围,在这篇文章中,是采用synopsys的设计流程,对数字电路进行功耗分析,生成功耗分析报告的流程.分析的对象是逻辑综合之后布局布线之前的功耗分析,以及布局布线之后的功耗分析. Synopsys做功耗分析使用到的工具是:Primetime PX, Prime Rail.PTPX可以在逻辑综合之后就进行功耗预估.PrimeTime PX是集成在PrimeTime里面的工具,虽然他可以做功耗分析,但是毕竟不是sign-off工具.真正到最后的sign-off,如果对功耗的要求很高

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

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