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

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

本篇分析bitmap的数据结构的设计,并基于此分析bitmap的工作机制. 为了后面更清楚的理解,先有个总体印象,给出整体的结构图: 在下面的描述中涉及到的内容可以对照到上图中相应部分,便于理解. 首先,我们从宏观的角度来分析整体结构.bitmap file存在于磁盘,内部存放着很多个bit,每个bit对应于磁盘数据中的一个chunk.在内存空间中也存在一个区域存放bitmap file缓存,与磁盘bitmap file的每个bit一一对应.内存空间中还存在一个区域存放filemap_attr,…

最近在做bwraid的R6的设计工作,需要调研一下bitmap下刷磁盘的IO属性(是否为SYNC IO),还有raid5中bitmap的存储和工作方式. 1.bitmap刷磁盘是否为 SYNC IO? 这样分为两种情况进行分析.前面写过的博客中提到过:bitmap可以有两种存储方式,一种是internal,一种是external.internal bitmap是存放在raid设备的成员盘的superblock附近(可以在之前也可以在之后),而external是单独指定一个文件用来存放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(…

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

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

五.Raid1读流程分析 两个月前,刚刚接触raid1,就阅读了raid1读流程的代码,那个时候写了一篇博客.现在回过头看看,那篇的错误很多,并且很多地方没有表述清楚.所以还是决定重新写一篇以更正之前理解的错误和不足之处,与大家分享.博客上不好排版,希望不会对表述产生影响.还有理解上的不足之处,希望批评指正.我阅读的代码的linux内核版本是2.6.32.61. 正确读流程的总体步骤是,raid1接收上层的读bio,申请一个r1_bio结构.然后根据read balance算法选出盘阵中的一块盘…

这篇博文不足之处较多,重新整理了一下,链接:http://www.cnblogs.com/fangpei/p/3890873.html 我阅读的代码的linux内核版本是2.6.32.61.刚进实验室什么都不懂,处于摸索阶段,近期的任务就是阅读raid1的源码.第一次接触raid相关的东西,网上分析源码的资料又比较少,不详细.逐行阅读代码,做了笔记.如果要对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方面的各流程整理了一遍.网上和书上,能找到关于MD下的raid1的文档资料比较少.决定开始写一个系列的关于raid1的博客,之前写过的一篇读流程也会在之后加一些修改,我阅读的代码的linux内核版本是2.6.32.61.进入实验室的时间不长,关于磁盘管理等内核方面的理解不足或者有误之处,希望批评指正. 一.Raid1简介 Raid1又称为镜像磁盘阵列.由两块或者多块盘构成这样一个阵列,并且每块盘所存储的内容都是完全一致的.意思就是盘与盘之间互为镜像,而…

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

了解HBase架构的用户应该知道,HBase是一种基于LSM模型的分布式数据库.LSM的全称是Log-Structured Merge-Trees.即日志-结构化合并-树. 相比于Oracle普通索引所採用的B+树,LSM模型的最大特点就是,在读写之间採取一种平衡,牺牲部分读数据的性能,来大幅度的提升写数据的性能.通俗的讲,HBase写数据如此快,正是因为基于LSM模型,将数据写入内存和日志文件后即马上返回. 可是,数据始终在内存和日志中是不妥当的,首先内存毕竟是有限的稀缺资源.持续的写入会造成…

===================================================== ffdshow源代码分析系列文章列表: ffdshow 源代码分析 1: 整体结构 ffdshow 源代码分析 2: 位图覆盖滤镜(对话框部分Dialog) ffdshow 源代码分析 3: 位图覆盖滤镜(设置部分Settings) ffdshow 源代码分析 4: 位图覆盖滤镜(滤镜部分Filter) ffdshow 源代码分析 5: 位图覆盖滤镜(总结) ffdshow 源代码分析 6…

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

在<HBase源代码分析之HRegion上MemStore的flsuh流程(一)>.<HBase源代码分析之HRegion上MemStore的flsuh流程(二)>等文中.我们介绍了HRegion上Memstore flush的主体流程和主要细节. 可是,HRegion仅仅是HBase表中依照行的方向对一片连续的数据区域的抽象,它并不能对外提供单独的服务,供client或者HBase其他实体调用.而HRegion上MemStore的flush还是要通过HRegionServer来对…

继上篇文章<HBase源代码分析之HRegionServer上MemStore的flush处理流程(一)>遗留的问题之后,本文我们接着研究HRegionServer上MemStore的flush处理流程.重点讲述下怎样选择一个HRegion进行flush以缓解MemStore压力,还有HRegion的flush是怎样发起的. 我们先来看下第一个问题:怎样选择一个HRegion进行flush以缓解MemStore压力.上文中我们讲到过flush处理线程假设从flushQueue队列中拉取出的一个…

继上篇<HBase源代码分析之HRegion上MemStore的flsuh流程(一)>之后.我们继续分析下HRegion上MemStore flush的核心方法internalFlushcache().它的主要流程如图所看到的: 当中.internalFlushcache()方法的代码例如以下: /** * Flush the memstore. Flushing the memstore is a little tricky. We have a lot of updates in the…

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

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

v2版本的MapReduce作业中,作业JOB_SETUP_COMPLETED事件的发生,即作业SETUP阶段完成事件,会触发作业由SETUP状态转换到RUNNING状态,而作业状态转换中涉及作业信息的处理,是由SetupCompletedTransition来完成的,它主要做了四件事: 1.通过设置作业Job的成员变量setupProgress为1,标记作业setup已完成: 2.调度作业Job的Map Task: 3.调度作业的JobReduce Task: 4.如果没有task了,则生成J…

尊重原创: http://blog.csdn.net/yuanzeyao/article/details/46765113 差点儿相同半年没有写博客了,一是由于工作比較忙,二是认为没有什么内容值得写,三是由于自己越来越懒了吧,只是近期我对Android中View的绘制机制有了一些新的认识.所以想记录下来并分享给大家.在之后的几篇博客中,我会给大家分享例如以下的内容: 1.View中measure(),layout(),draw()函数运行过程分析,带领大家详细分析View的尺寸測量过程,位置计算…

尊重原创:http://blog.csdn.net/yuanzeyao/article/details/46842891 本篇文章接着上篇文章的内容来继续讨论View的绘制机制,上篇文章中我们主要解说了View的measure过程.今天我们就来学习ViewGroup的measure过程.因为ViewGroup仅仅是一个抽象类,所以我们须要以一个详细的布局来分析measure过程,正如我上篇文章说的.我打算使用LinearLayout为例解说measure过程,假设你还没有读过上篇文章.那么建议你…

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

Android 输入法设置文章 Android 9.0 默认输入法的设置流程分析 Android 9.0 添加预置第三方输入法/设置默认输入法(软键盘) 前言 在上一篇文章  Android 9.0 添加预置第三方输入法/设置默认输入法(软键盘)    中我们可以通过设置enabled_input_methods和default_input_method两个key-value的值来显示的指定可选的输入法及默认输入法. 但是,查看Android原生代码,并没任何地方显示的设置这两个值,但是当开机后…

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

https://github.com/GeniusVJR/LearningNotes/blob/master/Part1/Android/Bitmap的分析与使用.md…

/** Spark SQL源代码分析系列文章*/ 自从去年Spark Submit 2013 Michael Armbrust分享了他的Catalyst,到至今1年多了,Spark SQL的贡献者从几人到了几十人,并且发展速度异常迅猛,究其原因,个人觉得有下面2点: 1.整合:将SQL类型的查询语言整合到 Spark 的核心RDD概念里.这样能够应用于多种任务,流处理,批处理,包含机器学习里都能够引入Sql.     2.效率:由于Shark受到hive的编程模型限制,无法再继续优化来适应Spa…

从CSDN中读取到关于spark structured streaming源代码分析不错的几篇文章 spark源码分析--事件总线LiveListenerBus spark事件总线的核心是LiveListenerBus,其内部维护了多个AsyncEventQueue队列用于存储和分发SparkListenerEvent事件. spark事件总线整体思想是生产消费者模式,消息事件实现了先进先出和异步投递,同时将事件的产生(例如spark core创建stage.提交job)和事件的处理(例如在Sp…