Linux 文件系统调优

Linux 文件系统性能并不只是“磁盘快不快”的问题。应用的 I/O 模式、页缓存策略、文件系统 mount options，以及 ext4 的内部参数，都会影响最终的吞吐、延迟和 CPU 消耗。 

1. 应用层 I/O 调优

应用层最重要的问题不是“怎么让磁盘更快”，而是：

应用到底需要什么样的 durability、cache 和 access pattern？

如果应用错误地要求了过强的持久化保证，性能可能下降一个数量级。

1.1 fsync vs O_DSYNC / O_RSYNC

fsync()

fsync(fd) 的语义是：

将文件相关的脏数据以及必要的元数据刷新到底层存储，使数据达到持久化要求。

例如：

write(fd, buf, size);

fsync(fd);

这种模式意味着每次写入后都要求显式 flush。

如果：

write

fsync

write

fsync

write

fsync

那么性能很容易受到 storage latency 限制。

尤其是在随机小 I/O 场景：

Application

│

write

│

fsync

│

▼

Storage

如果一次 fsync() 的实际持久化延迟是 1 ms，那么理论上单线程同步写入的上限可能只有约：

1000 fsync/s

因此，数据库、日志系统等通常会使用 batching/group commit，把多个逻辑操作合并到一次 flush 中。(比较常见)

O_DSYNC

打开文件时可以使用：

open("file", O_WRONLY | O_DSYNC);

它要求写操作的数据满足同步 I/O 的持久化语义，而不需要每次显式调用 fsync()。

典型模式：

write()

│

▼

O_DSYNC

│

▼

persistent storage

它适合：

●WAL

●journal

●transaction log

●对数据持久性要求较高的应用

但代价是每次相关写操作都可能受到存储设备 flush latency 的影响。

O_RSYNC

O_RSYNC 是一个比较容易被忽略的 flag，它主要用于控制同步读取的完成语义，要求 read 操作在相关写入满足同步条件后完成。

实际生产环境中，O_RSYNC 的使用远少于 fsync() 和 O_DSYNC。

因此面试中更重要的是理解：

fsync()

→application 主动要求同步

O_DSYNC

→write 本身具有同步 durability 语义

O_RSYNC

→read 的同步完成语义

1.2 posix_fadvise()

posix_fadvise() 用来向 kernel 提供：

“接下来我大概会怎么访问这个文件。”

例如：

posix_fadvise(fd, 0, 0, POSIX_FADV_SEQUENTIAL);

常见参数包括：

POSIX_FADV_SEQUENTIAL

告诉 kernel：

我会顺序读取这个文件

例如：

0 → 4K → 8K → 12K → 16K → ...

适合：

●日志扫描

●大文件读取

●backup

●ETL

POSIX_FADV_RANDOM

告诉 kernel：

访问模式是随机的

例如：

4K → 1GB → 32MB → 700MB → 128KB

这样 kernel 可以避免针对顺序访问进行不必要的 readahead。

POSIX_FADV_WILLNEED

告诉 kernel：

这些数据很快就会被访问

可以让 kernel 提前准备 page cache。

POSIX_FADV_DONTNEED

告诉 kernel：

这些 page 短期内不会再使用

例如扫描一个 100 GB 的文件：

read 4K

read 4K

read 4K

... 

如果这些数据全部留在 page cache，可能挤掉真正有价值的 cache。

因此可以结合：

posix_fadvise(fd, offset, length,

POSIX_FADV_DONTNEED);

降低 cache pollution。

1.3 madvise()

madvise() 与 posix_fadvise() 很像，但作用对象不同。

简单理解：

posix_fadvise()

→file descriptor / file I/O

madvise()

→process virtual memory

例如：

madvise(addr, length, MADV_SEQUENTIAL);

它告诉 kernel：

这个 virtual memory region 接下来会被顺序访问。

常见选项包括：

MADV_SEQUENTIAL

MADV_RANDOM

MADV_WILLNEED

MADV_DONTNEED

MADV_HUGEPAGE

MADV_NOHUGEPAGE

这对于 mmap() 类型的应用尤其重要：

File

│

▼

mmap()

│

▼

Virtual Memory

│

└── madvise()

因此：

read()/write()

→posix_fadvise()

mmap()

→madvise()

这是面试中非常值得记住的一组对比。

2. ext4 文件系统调优

应用层解决的是：

How does the application access data?

而 ext4 调优解决的是：

How does ext4 organize and persist data?

 主要涉及：

mount options

tune2fs

e2fsck

2.1 ext4 mount options

查看当前 mount options：

mount | grep ext4

或者：

findmnt -t ext4

典型输出：

/dev/nvme0n1p1 on / type ext4

(rw,relatime,data=ordered)

noatime / relatime

传统情况下，Linux 会维护文件的 access time：

atime

读取文件可能导致 inode metadata 更新。

对于大量 read workload：

read file

│

├──read data

│

└──update atime

可能产生额外的 metadata I/O。

因此常见优化是：

noatime

完全关闭 atime 更新。

或者：

relatime

只在必要情况下更新 atime。

现代 Linux 系统一般默认使用 relatime，因此不应该在没有 workload 证据的情况下盲目修改。

commit=

例如：

mount -o commit=30

控制 journal commit 的周期。

默认通常是几秒级。

更大的 commit interval：

更多数据

│

▼

batch

│

▼

一次 commit

可能减少 metadata/journal 操作，但同时意味着：

●crash 后可能有更多未提交数据

●durability latency 可能增加

所以它是一个典型的：

performance ↔ durability

trade-off。

lazytime

可以使用：

lazytime

减少时间戳更新产生的额外写入。

它让 inode timestamp 的更新更多地保留在内存中，再与其他 inode 写回一起处理。

对于 metadata-heavy workload 有时比较有价值。

2.2 tune2fs

tune2fs 主要用于修改 ext2/ext3/ext4 文件系统的参数。

查看文件系统信息：

sudo tune2fs -l /dev/nvme0n1p1

可以看到：

Filesystem volume name

Filesystem UUID

Filesystem features

Block size

Inode size

Mount count

Maximum mount count

Check interval

Journal size

例如：

sudo tune2fs -l /dev/nvme0n1p1 | less

Reserved blocks

ext4 通常会保留一部分 block：

Reserved block percentage

可以查看：

tune2fs -l /dev/nvme0n1p1

对于普通 server，默认保留空间可能比较合理。

但是对于一个非常大的数据盘，例如：

10 TB

即使只保留 5%，也意味着：

500 GB

因此对于专门的数据盘，可以根据实际用途调整 reserved blocks。

例如：

sudo tune2fs -m 1 /dev/nvme0n1p1

将 reserved blocks percentage 调整为 1%。

但不要把它简单理解为“reserved blocks 越少越好”。

Reserved blocks 可以帮助：

●root/admin 在磁盘接近满时继续工作

●避免 filesystem 完全耗尽

●降低严重 fragmentation 的风险

所以生产系统需要根据磁盘用途决定。

2.3 e2fsck

e2fsck 用于检查和修复 ext2/ext3/ext4 filesystem。

最基本：

sudo e2fsck /dev/nvme0n1p1 

但是要特别注意：

不要在正在挂载并使用的 filesystem 上随意运行 e2fsck。

通常应该：

unmount

│

▼

e2fsck

│

▼

mount

例如：

sudo umount /data

sudo e2fsck /dev/nvme0n1p1

sudo mount /data

e2fsck 和性能的关系

e2fsck 本身不是日常性能调优工具。

它解决的是：

filesystem consistency

例如：

inode

block bitmap

directory

journal

extent

之间出现不一致时，通过检查和修复恢复 filesystem consistency。

因此：

tune2fs

→filesystem configuration

e2fsck

→filesystem integrity

不要把 e2fsck 当成类似 fsck = filesystem performance optimizer。

3. 一套实际的 ext4 调优思路

生产环境中，不应该一上来执行：

mount -o noatime,...

而应该先确认 workload。

例如一个数据库服务器：

Application

│WAL

▼

fsync / O_DSYNC

│

▼

Page Cache

│

▼

ext4

├──journal

├──metadata

└──data

▼

NVMe

首先观察：

iostat -xz 1

vmstat 1

pidstat -d 1

再结合：

cat /proc/meminfo

mount

findmnt

tune2fs -l /dev/xxx

判断瓶颈到底属于：

Application I/O pattern

│

├──sync I/O

├──random I/O

├──sequential I/O

└──excessive fsync

│

▼

PageCache

│

▼

ext4

│

├──journal

├──metadata

└──fragmentation

│

▼

BlockDevice

4. 总结

Linux filesystem tuning 最重要的不是记住几个 sysctl 或 mount option，而是建立完整的 I/O 模型：

最终可以把 filesystem performance 简化成三个核心问题：

1. Application：

我到底需要什么durability？

2. Cache：

哪些数据应该进入/留在page cache 

3. Filesystem：

ext4应该用什么方式组织、journal 和写回数据？

最好的 filesystem tuning 往往不是“把参数调得更激进”，而是让 application I/O semantics、page cache 和 filesystem semantics 与实际 workload 相匹配。