IO写流程分析

最新推荐文章于 2025-06-11 01:01:27 发布

原创

最新推荐文章于 2025-06-11 01:01:27 发布 · 1.1k 阅读

5 ·

CC 4.0 BY-SA版权

文章标签：

#linux I/O

本文深入探讨Linux的IO写流程，从系统调用、VFS层、pdflush内核线程、IO调度器（包括Noop、Deadline、Anticipatory、CFQ算法）等方面详细分析，介绍了IO性能分析命令和相关内核参数。强调了IO调度器在优化系统性能中的作用，并提供了更改调度算法的方法，以及磁盘碎片整理和其它IO相关命令。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

IO写流程分析

IO 写流程图示：

系统调用

read系统调用的处理分为用户空间和内核空间处理两部分。其中，用户空间处理只是通过0x80中断陷入内核，接着调用其中断服务例程，即sys_read以进入内核处理流程。

对于read系统调用在内核的处理，如上图所述，经过了VFS、具体文件系统，如ext2、页高速缓冲存层、通用块层、IO调度层、设备驱动层、和设备层。其中，VFS主要是用来屏蔽下层具体文件系统操作的差异，对上提供一个统一接口，正是因为有了这个层次，所以可以把设备抽象成文件。具体文件系统，则定义了自己的块大小、操作集合等。引入cache层的目的，是为了提高IO效率。它缓存了磁盘上的部分数据，当请求到达时，如果在cache中存在该数据且是最新的，则直接将其传递给用户程序，免除了对底层磁盘的操作。通用块层的主要工作是，接收上层发出的磁盘请求，并最终发出IO请求（BIO）。IO调度层则试图根据设置好的调度算法对通用块层的bio请求合并和排序，回调驱动层提供的请求处理函数，以处理具体的IO请求。驱动层的驱动程序对应具体的物理设备，它从上层取出IO请求，并根据该IO请求中指定的信息，通过向具体块设备的设备控制器发送命令的方式，来操纵设备传输数据。设备层都是具体的物理设备。

在这里插入图片描述

VFS层：

内核函数sys_read是read系统调用在该层的入口点。它根据文件fd指定的索引，从当前进程描述符中取出相应的file对象，并调用vfs_read执行文件读取操作。vfs_read会调用与具体文件相关的read函数执行读取操作，file->f_op.read。然后，VFS将控制权交给了ext2文件系统。（ext2在此作为示例，进行解析）

pdflush

在linux操作系统中，写操作是异步的，即写操作返回的时候数据并没有真正写到磁盘上，而是先写到了系统cache里，随后由pdflush内核线程将系统中的脏页写到磁盘上，在下面几种情况下，
系统会唤醒pdflush回写脏页：

定时方式：
定时机制定时唤醒pdflush内核线程，周期为/proc/sys/vm/dirty_writeback_centisecs ，单位
是(1/100)秒，每次周期性唤醒的pdflush线程并不是回写所有的脏页，而是只回写变脏时间超过
/proc/sys/vm/dirty_expire_centisecs（单位也是1/100秒）。
注意：变脏的时间是以文件的inode节点变脏的时间为基准的，也就是说如果某个inode节点是10秒前变脏的，
pdflush就认为这个inode对应的所有脏页的变脏时间都是10秒前，即使可能部分页面真正变脏的时间不到10秒，
细节可以查看内核函数wb_kupdate()。
内存不足的时候：
这时并不将所有的dirty页写到磁盘，而是每次写大概1024个页面，直到空闲页面满足需求为止。
写操作时发现脏页超过一定比例：
当脏页占系统内存的比例超过 /proc/sys/vm/dirty_background_ratio 的时候，write系统调用会唤醒
pdflush回写dirty page,直到脏页比例低于/proc/sys/vm/dirty_background_ratio，但write系统调
用不会被阻塞，立即返回。当脏页占系统内存的比例超过/proc/sys/vm/dirty_ratio的时候， write系
统调用会被被阻塞，主动回写dirty page，直到脏页比例低于/proc/sys/vm/dirty_ratio，这一点在
2.4内核中是没有的。
用户调用sync系统调用：
这是系统会唤醒pdflush直到所有的脏页都已经写到磁盘为止。

IO Scheduler

每个块设备或者块设备的分区，都对应有自身的请求队列(request_queue),而每个请求队列都可以选择一个I/O调度器来协调所递交的request。I/O调度器的基本目的是将请求按照它们对应在块设备上的扇区号进行排列，以减少磁头的移动，提高效率。每个设备的请求队列里的请求将按顺序被响应。实际上，除了这个队列，每个调度器自身都维护有不同数量的队列，用来对递交上来的request进行处理，而排在队列最前面的request将适时被移动到请求队列中等待响应。

内核中实现的IO调度器主要有四种–Noop,Deadline,CFG, Anticipatory。

1. Noop算法

Noop调度算法是内核中最简单的IO调度算法。Noop调度算法也叫作电梯调度算法，它将IO请求放入到一个FIFO队列中，然后逐个执行这些IO请求，当然对于一些在磁盘上连续的IO请求，Noop算法会适当做一些合并。这个调度算法特别适合那些不希望调度器重新组织IO请求顺序的应用。

这种调度算法在以下场景中优势比较明显：

1）在IO调度器下方有更加智能的IO调度设备。如果您的Block Device Drivers是Raid，或者SAN，NAS等存储设备，这些设备会更好地组织IO请求，不用IO调度器去做额外的调度工作；

2）上层的应用程序比IO调度器更懂底层设备。或者说上层应用程序到达IO调度器的IO请求已经是它经过精心优化的，那么IO调度器就不需要画蛇添足，只需要按序执行上层传达下来的IO请求即可。

3）对于一些非旋转磁头氏的存储设备，使用Noop的效果更好。因为对于旋转磁头式的磁盘来说，IO调度器的请求重组要花费一定的CPU时间，但是对于SSD磁盘来说，这些重组IO请求的CPU时间可以节省下来，因为SSD提供了更智能的请求调度算法，不需要内核去画蛇添足。这篇文章提及了SSD中使用Noop效果会更好。

2. Deadline算法

Deadline算法的核心在于保证每个IO请求在一定的时间内一定要被服务到，以此来避免某个请求饥饿。

Deadline算法中引入了四个队列，这四个队列可以分为两类，每一类都由读和写两类队列组成，一类队列用来对请求按起始扇区序号进行排序，通过红黑树来组织，称为sort_list；另一类对请求按它们的生成时间进行排序，由链表来组织，称为fifo_list。每当确定了一个传输方向(读或写)，那么将会从相应的sort_list中将一批连续请求dispatch到requst_queue的请求队列里，具体的数目由fifo_batch来确定。只有下面三种情况才会导致一次批量传输的结束：

1）对应的sort_list中已经没有请求了

2）下一个请求的扇区不满足递增的要求

3）上一个请求已经是批量传输的最后一个请求了。

所有的请求在生成时都会被赋上一个期限值(根据jiffies)，并按期限值排序在fifo_list中，读请求的期限时长默认为为500ms，写请求的期限时长默认为5s，可以看出内核对读请求是十分偏心的，其实不仅如此，在deadline调度器中，还定义了一个starved和writes_starved，writes_starved默认为2，可以理解为写请求的饥饿线，内核总是优先处理读请求，starved表明当前处理的读请求批数，只有starved超过了writes_starved后，才会去考虑写请求。因此，假如一个写请求的期限已经超过，该请求也不一定会被立刻响应，因为读请求的batch还没处理完，即使处理完，也必须等到starved超过writes_starved才有机会被响应。为什么内核会偏袒读请求？这是从整体性能上进行考虑的。读请求和应用程序的关系是同步的，因为应用程序要等待读取的内容完毕，才能进行下一步工作，因此读请求会阻塞进程，而写请求则不一样，应用程序发出写请求后，内存的内容何时写入块设备对程序的影响并不大，所以调度器会优先处理读请求。

默认情况下，读请求