方法2: online fsck
ZFS，BTRFS 等由于采用了 COW 机制，对写入磁盘的数据不会再进行修改，保证存盘数据的稳定性，在恢复之后可以立即对外提供服务，将对断电时刻的数据检查作为一个优先级较低的操作（ZFS为scrub操作），可以和文件系统的正常操作并行执行，一旦有正常的读写等操作，将会停止 fsck 过程，减少对于应用性能的影响。
由于数据库等系统需要尽可能的在线提供服务，所以我们希望能够尽可能的缩短宕机后的启动时间。所以，如果可以实现 online fsck 的功能，则可以尽可能的缩短系统启动的时间，同时保证文件系统不被破坏。
目前已知的可以进行online fsck的文件系统是 zfs, ffs, btrfs。
Ted 给出的建议是可以考虑在分配磁盘块的时候在相应的 block group 上添加相应的标记，表明这个block group 正在进行磁盘块的分配，在出现宕机后，这个 block group 的数据只进行读操作，所有写操作都会被映射到其他的 block group中。这样可以尽可能的保证文件系统的一致性（来自ext4 workshop总结）。
鉴于kernel mainline已经明确表明不会接受ext4 snapshot的 patch，所以基于 fs 的 snapshot 进行 online fsck无法进行，可以尝试结合比较成熟的 lvm 快照为 fsck 提速。
Andreas的回复： *
When you write about online e2fsck, what do you mean exactly? It is already possible
with LVM to create a read-only snapshot of a device and run read-only e2fsck. This
works because the LVM snapshot is hooked to ext4 to freeze the filesystem and flush
the journal before the snapshot is done.
Ext4 snapshots vs lvm snapshots
* 如何在已有的分区上创建lvm卷组 思路：
遇到宕机/掉电导致的 fsck 时间过长时，将已有的分区转换为 lvm 分区，然后在lvm快照的基础上进行 online fsck，此时文件系统可以挂载供应用读取（读写未出错的文件）。 优势：从根本上免除了 fsck 带来带来的时延。 劣势/待解决问题