是的，linux以前就有文件系统的冻结，但是那里的冻结仅仅意味着锁住文件系统，实现上就是一个简单的信号量完成的，在所谓的freeze的时 候，down信号量，然后thaw的时候up信号量，仅此而已，那时用的信号量是block_device的bd_mount_sem，其实就是阻止了重 新mount这个文件系统，这样当然可以实现保护，但是真的执行起来情况却十分混乱，因为一旦有个执行绪thaw了文件系统，也就是说up了 bd_mount_sem，那么任何在down状态等待的执行绪都有可能从down返回，这完全取决于先后顺序，因为信号量本身有一个等待列表，up的语 义就是从这个列表的最开始取出一个，把信号量给它就可以了。以前的那个freeze实现是很脆弱的，根本没有考虑到争抢bd_mount_sem信号量实 体们的复杂性，比如说，一个进程freeze了一个文件系统，本意是想做快照，另一个进程不知道文件系统已经freeze了，该进程也想freeze这个 文件系统，它的意图是做镜像备份，可是文件系统已经被 freeze了，于是第二个进程就要在bd_mount_sem信号量上睡眠等待，等第一个进程完成再开始运行，这没有什么问题，因为第一个进程 freeze这个文件系统之后根本就不能再改动它了，两个进程对文件系统都是只读的，对于读，没有必要锁，如果能并行运行这两个进程性能一定很高，可是老 的实现并没有这么实现，这是第一个问题；第二个问题就是如果在第一个进程down掉bd_mount_sem以后，第二个进程开始进入down掉 bd_mount_sem之前对该文件系统有一个mount请求的话，那么第一个进程up掉bd_mount_sem之后，信号量将被这个mount进程 夺取（因为等待在信号量上的进程是被顺序唤醒的），于是第二个进程将再次等待，更为严重的是，在第二个进程终于可以down掉bd_mount_sem 时，该文件系统已经被mount到两个挂载点了...新的内核强化了文件系统的freeze机制，它通过增加了一个引用计数来规范了信号量 bd_mount_sem的行为，代码如下：
struct super_block *freeze_bdev(struct block_device *bdev)
{
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1273509