聊聊Linux IO(中)

接上一篇聊聊Linux IO,先上一张全貌图:

640?wx_fmt=png

由图可见,从系统调用的接口再往下,Linux下的IO栈致大致有三个层次:

  1. 1.文件系统层,以 write(2) 为例,内核拷贝了write(2)参数指定的用户态数据到文件系统Cache中,并适时向下层同步

  2. 2.块层,管理块设备的IO队列,对IO请求进行合并、排序(还记得操作系统课程学习过的IO调度算法吗?)

  3. 3.设备层,通过DMA与内存直接交互,完成数据和具体设备之间的交互

结合这个图,想想Linux系统编程里用到的Buffered IOmmap(2)Direct IO,这些机制怎么和Linux IO栈联系起来呢?上面的图有点复杂,我画一幅简图,把这些机制所在的位置添加进去:

640?wx_fmt=png

这下一目了然了吧?传统的Buffered IO使用read(2)读取文件的过程什么样的?假设要去读一个冷文件(Cache中不存在),open(2)打开文件内核后建立了一系列的数据结构,接下来调用read(2),到达文件系统这一层,发现Page Cache中不存在该位置的磁盘映射,然后创建相应的Page Cache并和相关的扇区关联。然后请求继续到达块设备层,在IO队列里排队,接受一系列的调度后到达设备驱动层,此时一般使用DMA方式读取相应的磁盘扇区到Cache中,然后read(2)拷贝数据到用户提供的用户态buffer中去(read(2)的参数指出的)。

整个过程有几次拷贝?从磁盘到Page Cache算第一次的话,从Page Cache到用户态buffer就是第二次了。而mmap(2)做了什么?mmap(2)直接把Page Cache映射到了用户态的地址空间里了,所以mmap(2)的方式读文件是没有第二次拷贝过程的。那Direct IO做了什么?这个机制更狠,直接让用户态和块IO层对接,直接放弃Page Cache,从磁盘直接和用户态拷贝数据。好处是什么?写操作直接映射进程的buffer到磁盘扇区,以DMA的方式传输数据,减少了原本需要到Page Cache层的一次拷贝,提升了写的效率。对于读而言,第一次肯定也是快于传统的方式的,但是之后的读就不如传统方式了(当然也可以在用户态自己做Cache,有些商用数据库就是这么做的)。

除了传统的Buffered IO可以比较自由的用偏移+长度的方式读写文件之外,mmap(2)Direct IO均有数据按页对齐的要求,Direct IO还限制读写必须是底层存储设备块大小的整数倍(甚至Linux 2.4还要求是文件系统逻辑块的整数倍)。所以接口越来越底层,换来表面上的效率提升的背后,需要在应用程序这一层做更多的事情。所以想用好这些高级特性,除了深刻理解其背后的机制之外,也要在系统设计上下一番功夫。

(未完待续...)


轻轻一扫  欢迎关注~

640?wx_fmt=jpeg

如果觉得好,请

转发

转发

转发

猜你喜欢

转载自blog.csdn.net/p23onzq/article/details/82321241