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。
当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