linux内核奇遇记之md源代码解读之十五bitmap原理

linux内核奇遇记之md源代码解读之十五bitmap原理

转载请注明出处：http://blog.csdn.net/liumangxiong 

为人不识陈近南，走遍江湖也枉然。做raid不识bitmap，通通都是走过场。

那么bitmap究竟是何许人物，能够在raid5的场子里混得风生水起呢？话说最早raid5是没有bitmap这位门客的，突然有一天跑raid5的系统异常掉电了，客户发现异常掉电之后再写数据就出现了数据不一致的情况。查来查去发现raid5本身设计就有一个缺陷：raid5每次写至少要写两个磁盘，写过程中异常掉电的时候就会发现一个磁盘写完成而另一个磁盘没有写完成，就会引起条带处于不一致的状态下，而条带不一致会引起后面的写问题。

在没有bitmap的时候，raid5为了保证条带一致性，在异常掉电之后就要做一次全盘同步。在有业务流的情况下，这种同步少则一二十个小时，多则几天甚至一个多星期。然而回头看看，也就是因为几个条带的不一致而引起全盘同步，太大动干戈了。

为了解决这个问题，raid5引入了bitmap这位门客，那么这位门客是如何解决这个问题的呢？其实很简单，就是在每次raid5写的时候记录条带为脏，在写完成的时候记录条带为干净。在异常掉电的时候，未写完成的条带都被设置为脏，系统重启之后只需要同步这些脏的条带就可以了。

看到这里我们不禁拍手称赞，原来需要几天的重新同步而现在就几分钟就可以搞定了，而且修改的代码量又是如此之少。

然而事情并没有你想像中的那么顺利，如果你听过Joni Mitchell的<Both Sides Now>，你就会知道做每一件事情都要look at thing from both side。用中文来讲就是当获得了bitmap的好处时，需要付出什么样的成本呢？当然最优状态就是成本为零，但是每一位程序员都太乐观了。

首先，bitmap需要占用一定的磁盘空间，当然这对存储系统来说根本算不了什么。其次，在每次写之前都需要记录对应的bitmap为脏，更可恶的是这次写是同步的，这将直接导致raid5写性能的急剧下降。那么有什么更优的方案吗？我的想法是另一块更快的存储来存放bitmap，比如直接用SSD来存储bitmap。当然有条件的话还可以直接用内存保存bitmap，这又要涉及到内存的掉电保护了。

好吧，不管用什么方法来保存bitmap，bitmap的原理和实现是不会改变的。

转载请注明出处：http://blog.csdn.net/liumangxiong