RAID5代码走读-（5）其他

qincp-

其他
Strip的几个状态
STRIPE_BIT_DELAY
挂入处理第一个写bio的时候，会设置条带STRIPE_BIT_DELAY标志，该标志在release_stripe中清除，清除的条件是当前的bitmap写入批次编号大于标志设置时的批次编号。这说明从第一个写bio挂入条带后，bitmap至少被写入磁盘一次。
在STRIPE_BIT_DELAY被设置时，写操作将被延缓提交，即在本次调用handle_stripe5中，写操作不被提交。
STRIPE_PREREAD_ACTIVE以及STRIPE_DELAYED
这两个标志位对条带上的读请求是否立即提交进行控制。
如果条带上有读请求，一般为了提高效率，并不立即放入conf->handle_list中进行处理，而是进行等待，设置条带的STRIPE_DELAYED标志。将这个条带放入conf->delayed_list进行等待。
在守护进程raid5d中，如果handle_list为空，则唤醒delayed_list中的条带（raid5_activate_delayed），让他们不再等待。不再等待的标志就是设置条带的STRIPE_PREREAD_ACTIVE。而在设备被unplug（我翻译为插入，插上电以后设备开始工作，好像和英文字面意思相反）时，也会唤醒等待队列中的条带。唤醒后的条带STRIPE_DELAYED的标志被清除，并且被插入到conf->handle_list。
STRIPE_INSYNC和STRIPE_SYNCING
条带开始同步时，设置STRIPE_SYNCING标志，调用handle_stripe5进行同步处理。
STRIPE_INSYNC标志条带中的磁盘数据已经处于一致状态（内存中，未必已经写盘）。在设置条带为STRIPE_INSYNC时，同时会将STRIPE_SYNCING清除。
MD_RECOVERY_SYNC，MD_RECOVERY_RESHAPE
RAID5基本不管理MD_RECOVERY_SYNC标志，仅在reshape动作前将其清除。
MD_RECOVERY_RESHAPE标志磁阵处于reshape过程中，比较奇怪的是，这个标志在程序中只有设置，而没有清除动作，可能是这一段代码也不太成熟吧。设置了该标志，在每次同步请求sync_request中，直接处理reshape_request，即同步过程由reshape操作替代。

关于各队列

关于bitmap
对于RAID5中bitmap的使用，作者在代码中有一个注释说明。
Bitmap的写盘被批量处理，每个批次有一个编号，conf->seq_write是上一次成功写入bitmap的批次编号，而conf->seq_flush是已满足条件马上要进行的下一个批次，如果批次尚未准备好（假设一次只写入一个批次的话），conf->seq_flush和conf->seq_write是相等的。
在add_stripe_bio中，发现需要向条带写入数据块，调用bitmap_startwrite更新内存中的bitmap，其对应的写盘归入到下一个bitmap写入批次，即sh->bm_seq=conf->seq_flush+1。
当写准备就绪时，如果批次尚未写入，拔出（plug）设备，将条带放入队列bitmap_list等待。在设备被插入（unplug）时，对conf->seq_flush进行递增，说明bitmap写入批次已经准备好了。
在raid5d中，发现已经有一个新的写入批次准备好（seq_flush > seq_write），调用bitmap_unplug执行实际写盘。
偶尔可能会有bit被写盘两次（批次就绪后，但写入前，在add_stripe_bio中又插入了新的条带），但不会有bit被漏掉。

Raid5中，一个条带中多个磁盘，条带中的每个磁盘第一次写的时候，都会调用bitmap_startwrite，在磁盘写完层后，调用bitmap_endwrite函数。而不是以一个条带为单位调用这两个函数。这个是为了处理方便，bitmap_startwrite增加内存位图计数，bitmap_endwrite减少计数。只有在条带对应的写操作全部结束后，bitmap才会启动位图的清零写盘。
疑问
使用stripe，一个stripe中每个磁盘的缓存固定一个页，这样处理会比较简单，但会导致数据的复制，会影响到效率，从软件RAID角度而言，可能设计者考虑最大开销在XOR计算，所以这样选择。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/103238/showart_2044146.html