对linux-2.6.29内核Freezing filesystems和Tree RCU的新理解
今天是2009年3月24日,2.6.29 内核终于放出来了,盼星星盼月亮就盼这一天呢,等了两个多月,今天终于可以尝试一把了,在以前的Changelog上略微知道了一些新特性,可那只是大致 理论,没有看到最终代码之前永远都不会明白linux内核的巧妙。好几天没有写日志了,今天就写一些对linux新内核新特新的新理解,首先还是看看文件 系统的冻结吧。
是的,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)
{
©著作权归作者所有:来自51CTO博客作者dog250的原创作品,如需转载,请注明出处,否则将追究法律责任