浅墨: 聊聊Linux IO(中)——Linux内核中的IO栈
接上一篇浅墨: 聊聊Linux IO(上),先上一张全貌图[4]:
由图可见,从系统调用的接口再往下,Linux下的IO栈致大致有三个层次:
文件系统层,以
write(2)
为例,内核拷贝了write(2)
参数指定的用户态数据到文件系统Cache中,并适时向下层同步块层,管理块设备的IO队列,对IO请求进行合并、排序(还记得操作系统课程学习过的IO调度算法吗?)
设备层,通过DMA与内存直接交互,完成数据和具体设备之间的交互
结合这个图,想想Linux系统编程里用到的Buffered IO
、mmap(2)
、Direct IO
,这些机制怎么和Linux IO栈联系起来呢?上面的图有点复杂,我画一幅简图,把这些机制所在的位置添加进去:
这下一目了然了吧?传统的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还要求是文件系统逻辑块的整数倍)。所以接口越来越底层,换来表面上的效率提升的背后,需要在应用程序这一层做更多的事情。所以想用好这些高级特性,除了深刻理解其背后的机制之外,也要在系统设计上下一番功夫。
(未完)
查看"Linux阅码场"精华技术文章请移步:
扫描二维码关注"Linux阅码场"