最近在做bwraid的R6的设计工作，需要调研一下bitmap下刷磁盘的IO属性（是否为SYNC IO），还有raid5中bitmap的存储和工作方式。
1、bitmap刷磁盘是否为 SYNC IO？
这样分为两种情况进行分析。前面写过的博客中提到过：bitmap可以有两种存储方式，一种是internal，一种是external。internal bitmap是存放在raid设备的成员盘的superblock附近（可以在之前也可以在之后），而external是单独指定一个文件用来存放bitmap。
当bitmap以internal方式存放时，盘整中每个成员盘都会存放一份bitmap，这种情况的bitmap下刷为SYNC IO，此时下刷bitmap的bio属性BIO_RW_SYNCIO和BIO_RW_UNPLUG均有；
当bitmap以external方式存放是，整个盘阵的bitmap只有一份（很有可能存储在盘阵设备之外），这种情况的bitmap下刷不是SYNC IO。
SYNC IO意味着bio下发之后，不会停留在写缓存设备之后就认为已写入并返回，而会要直到IO落入真正的物理设备之后才会认为写入并返回。
2、bitmap在RAID5中如何存储和工作？
R5的bitmap与R1相比较总体上的工作方式一致，这里我们仅分析internal方式存储的bitmap，这种情况bitmap会存储在每个成员盘上（包括数据盘和校验盘）。
同样数据不一致则置1，一致则置0；“批量置1，延迟清0”的原则仍然适用；bitmap的刷磁盘的写IO为sync io（其实从磁盘读bitmap到内存中时的读IO也为sync io）。
要注意bitmap是针对R5设备而言，而非针对各个成员盘。也就是说bitmap的1个bit代表的是R5地址空间中的一个chunk的数据是否一致。内存中存储有唯一的一份bitmap，并且会在写请求下发之前将其固化到每个成员盘（包括数据盘和校验盘）。每个成员盘有一份bitmap，每份bitmap都相同，成员盘中存储的数据是否对称对其没有影响。
1) 假设场景是一块成员盘坏掉，换上新的盘，则需要做全盘恢复，与bitmap无关；
2) 假设场景是拔掉了一块盘，之后又将其插上，则根据bitmap来进行精准恢复（读取该成员盘之外的其他成员盘数据，算校验/数据并写入该成员盘)，此时没有掉电根据的bitmap为内存中的那份bitmap；
注：根据rdev->saved_raid_disk的值来判断是否为这种情况。
3) 假设场景是整个盘阵掉电，然后上电重启，则从一个可以工作的成员盘上读取bitmap到内存，然后进行精准恢复。
注：3.1) 重启之后，用户使用命令发送Assemble给mdadm；
3.2) mdadm处理这个命令，会调用start_array，而start_array会下发RUN_ARRAY的ioctl给md；
3.3) md接收到该ioctl之后函数，读取成员盘上的bitmap到内存的调用路径：
md_ioctl -> do_md_run -> bitmap_create -> bitmap_init_from_disk -> read_sb_page -> sync_page_io
2) 假设场景是拔掉了一块盘，之后又将其插上，则根据bitmap来进行精准恢复（读取该成员盘之外的其他成员盘数据，算校验/数据并写入该成员盘)，此时没有掉电根据的bitmap为内存中的那份bitmap；
注：根据rdev->saved_raid_disk的值来判断是否为这种情况。
3) 假设场景是整个盘阵掉电，然后上电重启，则从一个可以工作的成员盘上读取bitmap到内存，然后进行精准恢复。
注：3.1) 重启之后，用户使用命令发送Assemble给mdadm；
3.2) mdadm处理这个命令，会调用start_array，而start_array会下发RUN_ARRAY的ioctl给md；
3.3) md接收到该ioctl之后函数，读取成员盘上的bitmap到内存的调用路径：
md_ioctl -> do_md_run -> bitmap_create -> bitmap_init_from_disk -> read_sb_page -> sync_page_io