MD（七）In_sync标志与resync

这些文章已经写了好几年了，可能已经过时了。在MSN space和QQzone几经辗转之后，我想也许这些技术文章还是放在搞技术的博客中更能帮助人。于是做了一个艰难的决定，把这些文章一篇篇搬过来！绝对是原创的。

 

关于mddev->in_sync的作用我一直只是一知半解，前段时间终于有机会将它的用法重新理解了。原来它是出于数据安全考虑的。

考虑一下这样一种情况：一个RAID-5设备在进行读写。这个时候如果计算机突然掉电，也就是说很有可能一些写请求已经被子设备处理，而有些可能还没有被处理。要知道RAID-5的写请求必须要在parity也写完以后才算写完成。假设在同一个stripe中，数据已经被写入子设备，而parity还没有被写入，又或者parity已经被写入而某些数据还没被写入，无论哪种情况，可以想象的是，当这个RAID-5再次被重组以后这个stripe中parity已经与数据不再一致。根据我以前对RAID-5的分析（RAID-5（十二）），parity与数据必须是同步的，否则会有数据错误隐患。

那我们如何去解决这个问题？最简单的办法就是在RAID-5被重组后再次发起resync。但这种简单的办法开销是很大的，因为现在的磁盘动则几百G，要做完一次resync没几个小时是搞不定的，如果重组以后RAID-5就立即投入处理IO请求，那么resync估计做几天都有可能，那在这期间这个RAID-5是很脆弱的。然而，就目前这种情形，在无法确定哪个stripe有隐患的情况下，发起一次全面的resync是最可靠的办法了。

In_sync字段就是为了确定是否需要再发起resync。在2.4的内核中，也有类似的问题，但是并没有使用in_sync这种更为灵活的形式，其做法很死板：就是在MD运行起来以后，就将MD_SB_CLEAN标志从superblock中清掉，在MD停止的时候再重新设置回去，这样如果这时候发生非法关机，MD_SB_CLEAN标志就是被清除的，MD重组之后就知道应该要发起resync。我之所以说他死板，就是因为不管三七二十一，即使没有读写，或者读写都已经完成了，也还会发起resync。

再回过头来说说in_sync的灵活用法。因为只有在处理写请求的时候有可能存在这种问题，因此，在发起写请求的时候将in_sync设为0，表示：注意，我们可能需要resync。与此同时sb_dirty被设为1，更新superblock的操作开始执行，将superblock中的MD_SB_CLEAN标志清掉。那什么时候它会被设为1呢？两个地方，一是，如果所有的写都完成了，那么就可以将其设为1，另一个是MD正常停止。两种情况都回发起更新superblock，将MD_SB_CLEAN标志恢复。这里要罗嗦一句：以上讨论都是在初始resync已经完成以后的。大家看出来了吧，发起resync的条件更为严格了，避免了不必要的resync。

MD正常停止，就直接调用md_update_sb来更新superblock，没什么可多说的了。看看写完成时的处理，注意md_write_end函数，并没有我说的将in_sync置1的代码，也就是说并没有立即更新，只是根据safemode分两种处理。Safemode 2就是唤醒守护线程，守护线程会处理superblock更新；safemode 1则是延迟一段时间后再唤醒守护线程处理。这两种模式的具体用途我还不是特别清楚，有兴趣的话大家可以继续深入。

到此为止，我想对MD的讨论告一段落，MD有点凌乱，而且我还有不少地方没有仔细读过，不确定的地方还有不少，毕竟不如对RAID-5那般熟悉，没法做到条块分割，如果有什么纰漏或者谬误，请见谅，欢迎指正。