关于文件系统的一些问题

remaper

最近看了几天文件系统相关的代码（刚如行，很菜，问得不好莫怪）。想梳理一下bio被处理的流程
我所看的内核版本是：2.6.34.14

1、plug和unplug的含义没理解（不是什么激活不激活，而是这两个东西的具体角色，所参与的工作，结合流程来分析），plug和unplug的时机分别是什么？
2、从执行submit_bio之后，再到__make_request再到q->request_fn()，整个过程似乎是串行的。当然，__make_request未必会执行q->request_fn()，只有会在下面的情况下，才会触发：
out:
        if (unplug || !queue_should_plug(q))
                __generic_unplug_device(q);
所以又回到了第一个问题。submit_bio就感觉是在攒bio，攒的差不多了就触发了上面的代码，继而会执行q->request_fn()函数。，而q->request_fn是驱动提供的，实际上只是处理了一个request，似乎没别的。
3、在drivers/block/hd.c里，hd的request_queue竟然是一个全局的静态变量，那就是说所有硬盘的bio都会通过同一个队列来处理。
为什么不是一个物理设备，一个request_queque，因为我觉得这样可能并行会更好一点，至少解耦。
4、在block/blk-merge.c的blk_rq_map_sg函数里，new_segment的时候总是：
                        ...
                                sg->page_link &= ~0x02;
                                sg = sg_next(sg);
                        }
                        sg_set_page(sg, bvec->bv_page, nbytes, bvec->bv_offset);

而sg_next(sg)是有可能返回NULL的，但是sg_set_page并没有对sg检查，那内核怎么保证，sg_next返回非NULL？

remaper

自己顶啊，求爆虐，求刺激