磁盘 I/O 性能直接影响数据库、Web 服务器、消息队列等绝大多数服务端应用的吞吐量和延迟。Linux 在文件系统、挂载选项和内核调度层都提供了丰富的优化手段，但所有调整必须基于实际负载特征，盲目套用反而可能降低稳定性。
1. 文件系统选型
不同文件系统在稳定性、性能、数据完整性和高级功能上各有侧重。以下为生产环境最常见的三种：
ext4
- 最成熟的 Linux 文件系统，稳定性极佳，是绝大多数发行版的默认选项。
- 适合通用服务器负载：大量小文件、随机读写、日志存储。
- 最大文件系统 1EB，单文件最大 16TB，对绝大多数场景绰绰有余。
- 不支持写时复制（COW）、快照、压缩等高级功能，也不擅长超大目录（几百万文件）的高并发操作。
- 推荐场景：根分区、通用数据盘、不确定用什么时的默认选择。
XFS
- 由 SGI 设计，专为高并发和大文件顺序读写优化，是 Red Hat 系发行版的默认文件系统。
- 支持在线扩容（
xfs_growfs），但不支持在线缩容。 - 极大提升了元数据操作的并行性，在多线程连续读写大文件（如视频流、数据库表空间）时性能明显优于 ext4。
- 日志采用异步写入元数据，断电时文件系统结构安全，但最近几秒的修改可能丢失（可通过挂载参数调整）。
- 推荐场景：数据库服务器、大型对象存储、日志聚合、流媒体服务。
btrfs
- 现代化的 COW 文件系统，支持快照、子卷、压缩、数据校验与自修复、在线扩容/缩容等功能，类似 ZFS 的定位。
- 功能强大，但在极端压力下的稳定性仍在不断成熟，部分发行版仍将其标记为实验性。
- 适合需要快照备份、灵活卷管理的场景，或测试/开发环境。
- 推荐场景：需要快照和回滚的容器宿主机、文件服务器、开发环境。生产关键数据需谨慎评估具体内核版本稳定性。
其他：
- ZFS（通过 OpenZFS 模块）：功能最丰富，但需单独安装内核模块，内存开销较大，适合对数据完整性有极致要求的 NAS/SAN 环境。
- F2FS：专为闪存存储设计，适合 SSD 密集读写，移动端和部分嵌入式场景。
选型建议：若不确定，ext4 是稳妥选择；若负载明确为大文件高并发读写，XFS 是性能首选；若看重快照和灵活管理，可尝试 btrfs（需充分测试内核版本兼容性）。
2. 挂载参数
文件系统的挂载选项（mount -o 或 /etc/fstab 第四列）直接影响性能和行为。以下是常用优化参数：
| 参数 | 作用 | 建议 |
|------|------|------|
| noatime | 禁止更新文件访问时间戳，减少大量不必要的磁盘写操作。 | 强烈推荐，几乎所有场景均可启用。 |
| nodiratime | 仅禁止更新目录的访问时间，noatime 已隐含禁用目录访问时间，可省略。 | 若仅用 relatime 可不用。 |
| relatime | 相对访问时间更新：仅当文件被修改过或之前访问时间早于修改时间时才更新。是现代内核默认选项。 | 保守场景可替代 noatime，性能提升接近但保留部分兼容性。 |
| data=ordered | ext4 默认模式，数据先写入，元数据日志后写入。保证文件内容与元数据一致，性能与安全平衡。 | 保持默认。 |
| data=writeback | 仅记录元数据日志，数据写入顺序不保证，崩溃后可能出现旧数据残留。性能更高但安全性略低。 | 仅在可接受极低概率文件损坏的临时数据盘使用。 勿用于数据库和日志盘。 |
| discard | 实时向 SSD 发送 TRIM 命令，删除块时立即通知闪存释放空间。可能引入 IO 延迟。 | 笔记本电脑或轻度负载可用；服务器通常使用 定时 fstrim 替代。 |
| nobarrier | 禁用写屏障，牺牲崩溃一致性换取小幅度随机写性能提升。极其危险，断电或系统崩溃极易导致文件系统损坏。 | 强烈不推荐，除非有电池备份写入缓存的 RAID 卡。 |
| noatime,nodiratime | 同上，组合禁用访问时间。 | 直接使用 noatime 即可。 |
| commit=N | 将 ext4 日志提交间时隔设为 N 秒（默认 5） 。减少频繁日志写，但增大崩溃丢失窗口。 | 可适当提高至 30 秒，用于写负载极大但断电丢失风险可控的盘。 |
生产环境建议 fstab 示例：
/dev/sdb1 /data ext4 defaults,noatime 0 2或针对 SSD、XFS：
UUID=xxx /data xfs defaults,noatime,nodiscard 0 2并配合 systemd timer 或 cron 定期执行 fstrim /data。
3. IO 调度算法
Linux 内核的 I/O 调度器负责决定哪些进程的读写请求先被发送到磁盘。现代内核在块设备层使用 multi-queue (blk-mq) 框架，可用的调度器如下：
查看和切换调度器：
cat /sys/block/sda/queue/scheduler # 查看当前调度器及可用列表（方括号内为当前）
echo bfq > /sys/block/sda/queue/scheduler # 临时切换永久设置需通过内核启动参数，例如 elevator=bfq。
常用调度器选择：
- none（或 noop）：不做额外的排序和合并，适合高端的 NVMe 和硬件 RAID 卡，因为硬件已完成优化，软件调度反而徒增 CPU 消耗。虚拟化环境和高端 SSD 首选。
- mq-deadline：保证延迟的调度器，确保每个 I/O 请求的最大等待时间不超过设定值（默认 500ms）。同时具备简单的读写批次调度。数据库、交互式服务的最佳通用选择。它能在不牺牲太多吞吐量的前提下保证延迟。
- kyber：针对快速设备（SSD/NVMe）设计，通过动态令牌控制 I/O 队列深度来调节延迟。适合要求低延迟且需要避免设备队列过载的场景。低延迟 SSD 场景可尝试。
- bfq：预算公平排队调度器，分配给每个进程一个 I/O 时间片，擅长在多任务同时读写时维持交互体验。桌面和交互式站点的首选，但在高并发服务器场景下可能引入额外 CPU 开销和吞吐量下降。
推荐策略：
- 机械硬盘（HDD）：mq-deadline 或 bfq，保证公平和延迟。
- SATA/SAS SSD：mq-deadline 通常表现最佳。
- NVMe SSD 或高端 RAID 卡：none，把决策交给硬件和块层。
- 桌面系统：bfq，改善多任务磁盘响应。
小结
磁盘 I/O 优化是一个系统工作，文件系统决定基础性能天花板，挂载参数减少不必要开销，调度器为不同负载精准调度。实际调整时，务必结合 iostat、iotop、perf 等工具评估效果，并始终测试后再上线。没有银弹，只有最符合自己业务模式的选择。