MD中bitmap源代码分析--SYNC IO和RAID5的补充

【MD中bitmap源代码分析--SYNC IO和RAID5的补充】的更多相关文章

MD中bitmap源代码分析--SYNC IO和RAID5的补充

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

MD中bitmap源代码分析--数据结构

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

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

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(…

Hadoop源代码分析【IO专题】

由于Hadoop的MapReduce和HDFS都有通信的需求,需要对通信的对象进行序列化.Hadoop并没有采用Java的序列化(因为Java序列化比较复杂,且不能深度控制),而是引入了它自己的系统.org.apache.hadoop.io中定义了大量的可序列化对象,他们都实现了Writable接口.实现了Writable接口的一个典型例子如下: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 public class MyWritab…