该文章主要讲把日志文件系统（如ext3）与底层的软raid结合起来，引入declared mode，在写入数据前，先记录日志，然后在意外崩溃的时候能够根据日志来判断哪些数据是不一致的，从而减少了全量同步，缩短了处于故障恢复状态的时间。
为了实现这个功能，为软raid增加了一个新的接口，verify read，在收到这种请求时，先进行数据的校验判断，如果有不一致的数据，则重写镜像或校验数据来保持一致。
如果把日志记录到该阵列中，会降低阵列的性能，高端阵列一般是采用一个NVRAM来记录日志，
另一种方式是把日志记录到阵列的bitmap中，不过这样都会影响性能。（就是mdraid的bitmap机制，http://www.linuxsymposium.org/archives/OLS/Reprints-2003/LinuxSymposium2003.pdf#page=109）
这篇文章主要讲的就是利用文件系统的恢复机制，来解决软raid崩溃时全量同步的问题。
这里是基于日志的文件系统（如ext3之类的），在写数据到磁盘之前，先记录日志，然后再写数据，写成功后再记录commit日志。
这样在文件系统崩溃时可以根据日志来进行恢复，日志中已经commit成功的是不需要恢复的。
为了利用这个机制，为软raid引入veryfy read，就是恢复的时候，文件系统向软raid发veryfy read请求，就是在buffer head中增加一个raid synchronize的标记，软raid在收到带有这个标记的请求时，才进行检查（raid1是检查源盘和镜像盘对应的数据是否一致，raid5是检查校验块和由数据块计算的校验值是否一致），如果不一致，就进行同步（raid1让各个镜像盘的对应数据一样，raid5是将新计算的校验值写入校验块中）。这样就避免了软raid崩溃时，全盘扫描进行比对了。
局限在于：
1）必须是基于日志的文件系统，而且必须是软raid上建的文件系统，如果软raid上没有文件系统，而直接裸盘使用，那么就不适用。
2）对于跨网络的软raid（使用iscsi或nbd等方式），文章中的在请求上加了一个synchronize标记还不一定可行，因为需要iscsi协议或nbd里有空闲字段用于存放synchronize标记才行。
值得借鉴的地方：
1）能够根据请求的类型来判断是否进行软raid的数据恢复，而不是进行全盘扫描；
2）对于云硬盘来说，目前采用的bitmap机制其实就是把日志记录到bitmap中（文章中也有提到），不过在整个机房断电重启这种极端情况，bitmap也丢失不可用了，目前就只能全盘扫描进行同步（这里的全盘扫描进行同步是直接将一块盘的数据完全拷贝到另一块盘，还是需要根据chunk块大小进行比对，如果是一样的，就不进行数据拷贝，不过也必须先从两个镜像中都读出数据来，目前认为是第二种），因为我们使用的extern bitmap，这种极端情况下，bitmap不可用，如果是intern bitmap，那对于这种情况也是可以不用全量同步的，只不过intern bitmap是存放在阵列本身，对于正常请求来说开销较大。