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(3个page)个chunk的数据,对整个盘阵仅仅只有这1次写请求,分析例子如下5步操作:

  1、 raid1的make_request()接收这个写请求,在将写bio挂到pending_list上之后,执行bitmap_startwrite(),然后激活守护进程。bitmap_startwrite()设置bitmap file的这3page的页属性为BITMAP_PAGE_DIRTY,每个bit对应的*bmc置为2,马上*bmc++,此时这些*bmc = 3

  2、 激活守护进程之后,在守护进程下发写请求之前,执行bitmap_unplug(),遍历bitmap file缓存的所有page,因为只有这3个page属性是BITMAP_PAGE_DIRTY,所以只操作这3个page。以page为单位,将这3pagebit下刷到磁盘bitmap file清除各page对应的页属性BITMAP_PAGE_DIRTY等待bit刷磁盘完全结束之后,再进行写bio下发

  3、 当最后一个写bio成功回调之后,执行bitmap_endwrite(),对于这3个page对应的每个bit的*bmc递减,此时这些*bmc = 23page的页属性置为BITMAP_PAGE_CLEAN

  4、 当守护进程执行时,调用bitmap_daemon_work(),遍历整个bitmap file缓存。对这3个page的每个bit的*bmc设置为1,并对这3个page再增加BITMAP_PAGE_NEEDWRITE页属性

  5、 当守护进程再次执行时,再次调用bitmap_daemon_work(),遍历整个bitmap file缓存。对这3个page页属性BITMAP_PAGE_CLEAN清除,相应的每个bit的*bmc设置为0bit逐一清零,将3个页属性BITMAP_PAGE_ NEEDWRITE清除,bitmap对于3个page的bit下刷到磁盘

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

时间: 2024-10-16 18:50:24

MD中bitmap源代码分析--状态机实例的相关文章

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

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

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在这之后刷磁盘的话,当写磁盘过程中发生故障,比如掉电

Java中arraylist和linkedlist源代码分析与性能比較

Java中arraylist和linkedlist源代码分析与性能比較 1,简单介绍 在java开发中比較经常使用的数据结构是arraylist和linkedlist,本文主要从源代码角度分析arraylist和linkedlist的性能. 2,arraylist源代码分析 Arraylist底层的数据结构是一个对象数组.有一个size的成员变量标记数组中元素的个数,例如以下图: * The array buffer into which the elements of the ArrayLis

FreeBSD 5.0中强制访问控制机制的使用与源代码分析【转】

本文主要讲述FreeBSD 5.0操作系统中新增的重要安全机制,即强制访问控制机制(MAC)的使用与源代码分析,主要包括强制访问控制框架及多级安全(MLS)策略两部分内容.这一部分讲述要将MAC框架与MLS策略用起来,应该做的一些工作,以及如何有效使用它们的问题. ? 强制访问控制(英文缩写MAC)是实现操作系统安全的一个重要的方法,现在几乎所有的安全操作系统都采用强制访问控制作为其核心安全机制之一.强制访问控制是对操作系统的各种客体(如文件.socket.系统FIFO.SCD.IPC等)进行细

Android 中View的绘制机制源代码分析 三

到眼下为止,measure过程已经解说完了,今天開始我们就来学习layout过程.只是在学习layout过程之前.大家有没有发现我换了编辑器,哈哈.最终下定决心从Html编辑器切换为markdown编辑器.这里之所以使用"下定决心"这个词.是由于毕竟Html编辑器使用好几年了.非常多习惯都已经养成了,要改变多年的习惯确实不易.相信这也是还有非常多人坚持使用Html编辑器的原因. 这也反应了一个现象.当人对某一事物非常熟悉时,一旦出现了新的事物想代替老的事物时,人们都有一种抵触的情绪,做

Android系统进程间通信(IPC)机制Binder中的Client获得Server远程接口过程源代码分析

文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/6633311 在上一篇文章中,我 们分析了Android系统进程间通信机制Binder中的Server在启动过程使用Service Manager的addService接口把自己添加到Service Manager守护过程中接受管理.在这一篇文章中,我们将深入到Binder驱动程序源代码去分析Client是如何通过Service Manager的

Twitter Storm源代码分析之ZooKeeper中的目录结构

徐明明博客:Twitter Storm源代码分析之ZooKeeper中的目录结构 我们知道Twitter Storm的所有的状态信息都是保存在Zookeeper里面,nimbus通过在zookeeper上面写状态信息来分配任务,supervisor,task通过从zookeeper中读状态来领取任务,同时supervisor, task也会定义发送心跳信息到zookeeper, 使得nimbus可以监控整个storm集群的状态, 从而可以重启一些挂掉的task.ZooKeeper 使得整个sto

Lighttpd1.4.20源代码分析 笔记 状态机之错误处理和连接关闭

这里所说的错误有两种: 1.http协议规定的错误,如404错误. 2.server执行过程中的错误.如write错误. 对于http协议规定的错误,这里的"错误"是针对client的. lighttpd返回相应的错误提示文件之后,相当于顺利的完毕了一次请求,仅仅是结果和client想要的不一样而已. 对于server执行中的错误,状态机进入CON_STATE_ERROR状态.常见的错误原因:client提前断开连接. 比方你不停的刷新页面.在你刷新的时候,前一次的连接没有完毕,但被浏