Top

【分享】Linux 下的 IO 以及缓存

网关设备, 语音中控设备等
Post Reply
Jason
Posts: 5

在实际的业务开发中，经常遇到由于掉电问题引起的写文件没有生效的问题，所以我们有必要研究一下根本原因。

缓存

cache.png

如图，当程序调用各类文件操作函数后，用户数据（User Data）到达磁盘（Disk）的流程如图所示。图中描述了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栈

Linux-storage-stack.png

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

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

  • 2. 块层，管理块设备的IO队列，对IO请求进行合并、排序

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

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

linux-io.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还要求是文件系统逻辑块的整数倍）。所以接口越来越底层，换来表面上的效率提升的背后，需要在应用程序这一层做更多的事情。

Page Cache 的同步

广义上Cache的同步方式有两种，即Write Through（写穿）和Write back（写回）. 从名字上就能看出这两种方式都是从写操作的不同处理方式引出的概念（纯读的话就不存在Cache一致性了，不是么）。对应到Linux的Page Cache上所谓Write Through就是指write(2)操作将数据拷贝到Page Cache后立即和下层进行同步的写操作，完成下层的更新后才返回。而Write back正好相反，指的是写完Page Cache就可以返回了。Page Cache到下层的更新操作是异步进行的。

Linux下Buffered IO默认使用的是Write back机制，即文件操作的写只写到Page Cache就返回，之后Page Cache到磁盘的更新操作是异步进行的。Page Cache中被修改的内存页称之为脏页（Dirty Page），脏页在特定的时候被一个叫做pdflush(Page Dirty Flush)的内核线程写入磁盘，写入的时机和条件如下：

  • 当空闲内存低于一个特定的阈值时，内核必须将脏页写回磁盘，以便释放内存。

  • 当脏页在内存中驻留时间超过一个特定的阈值时，内核必须将超时的脏页写回磁盘。

  • 用户进程调用sync(2)、fsync(2)、fdatasync(2)系统调用时，内核会执行相应的写回操作。

刷新策略由以下几个参数决定（数值单位均为1/100秒）：

Code: Select all

flush每隔5秒执行一次
# cat /proc/sys/vm/dirty_writeback_centisecs 
500
内存中驻留30秒以上的脏数据将由flush在下一次执行时写入磁盘
# cat /proc/sys/vm/dirty_expire_centisecs 
3000
若脏页占总物理内存10％以上，则触发flush把脏数据写回磁盘
# cat /proc/sys/vm/dirty_background_ratio 
10

默认是写回方式，如果想指定某个文件是写穿方式呢？即写操作的可靠性压倒效率的时候，能否做到呢？当然能，除了之前提到的fsync(2)之类的系统调用外，在open(2)打开文件时，传入O_SYNC这个flag即可实现。

Post Reply