在开始正式的讨论前,我先抛出几个问题:
write(2)
函数成功返回了,数据就已经成功写入磁盘了吗?此时设备断电会有影响吗?会丢失数据吗?write(2)
调用是原子的吗?多线程写文件是否要对文件加锁?有没有例外,比如O_APPEND
方式?mmap(2)
的方式读文件比传统的方式要快,因为少一次拷贝。真是这样吗?为什么少一次拷贝?如果你觉得这些问题都很简单,都能很明确的回答上来。那么很遗憾这篇文章不是为你准备的,你可以关掉网页去做其他更有意义的事情了。如果你觉得无法明确的回答这些问题,那么就耐心地读完这篇文章,相信不会浪费你的时间。受限于个人时间和文章篇幅,部分议题如果我不能给出更好的解释或者已有专业和严谨的资料,就只会给出相关的参考文献的链接,请读者自行参阅。
言归正传,我们的讨论从存储器的层次结构开始。
受限于存储介质的存取速率和成本,现代计算机的存储结构呈现为金字塔型[1]。越往塔顶,存取效率越高、但成本也越高,所以容量也就越小。得益于程序访问的局部性原理[2],这种节省成本的做法也能取得不俗的运行效率。从存储器的层次结构以及计算机对数据的处理方式来看,上层一般作为下层的Cache层来使用(广义上的Cache)。比如寄存器缓存CPU Cache的数据,CPU Cache L1~L3层视具体实现彼此缓存或直接缓存内存的数据,而内存往往缓存来自本地磁盘的数据。
本文主要讨论磁盘IO操作,故只聚焦于Local Disk的访问特性和其与DRAM之间的数据交互。
如图,当程序调用各类文件操作函数后,用户数据(User Data)到达磁盘(Disk)的流程如图所示[3]。图中描述了Linux下文件操作函数的层级关系和内存缓存层的存在位置。中间的黑色实线是用户态和内核态的分界线。
从上往下分析这张图,首先是C语言stdio
库定义的相关文件操作函数,这些都是用户态实现的跨平台封装函数。stdio
中实现的文件操作函数有自己的stdio buffer
,这是在用户态实现的缓存。此处使用缓存的原因很简单——系统调用总是昂贵的。如果用户代码以较小的size不断的读或写文件的话,stdio
库将多次的读或者写操作通过buffer进行聚合是可以提高程序运行效率的。stdio
库同时也支持fflush(3)
函数来主动的刷新buffer,主动的调用底层的系统调用立即更新buffer里的数据。特别地,setbuf(3)
函数可以对stdio
库的用户态buffer进行设置,甚至取消buffer的使用。
系统调用的read(2)/write(2)
和真实的磁盘读写之间也存在一层buffer,这里用术语Kernel buffer cache
来指代这一层缓存。在Linux下,文件的缓存习惯性的称之为Page Cache
,而更低一级的设备的缓存称之为Buffer Cache
. 这两个概念很容易混淆,这里简单的介绍下概念上的区别:Page Cache
用于缓存文件的内容,和文件系统比较相关。文件的内容需要映射到实际的物理磁盘,这种映射关系由文件系统来完成;Buffer Cache
用于缓存存储设备块(比如磁盘扇区)的数据,而不关心是否有文件系统的存在(文件系统的元数据缓存在Buffer Cache
中)。
综上,既然讨论Linux下的IO操作,自然是跳过stdio
库的用户态这一堆东西,直接讨论系统调用层面的概念了。对stdio
库的IO层有兴趣的同学可以自行去了解。从上文的描述中也介绍了文件的内核级缓存是保存在文件系统的Page Cache
中的。所以下篇的讨论基本上是讨论IO相关的系统调用和文件系统Page Cache
的一些机制。
(未完待续...)