第 13 章 文件系统、磁盘与 I/O 排查

第 7 章给出 fd 到 inode 的结构，第 9 章给出块层路径；本章回答现场真正要紧的三个问题：盘满在哪、I/O 慢在哪、谁在读写。

学习目标

读完本章，你应当能够：

1. 说出 ext4 三种日志模式（journal/ordered/writeback）各自保证什么、崩溃后会看到什么形态的坏数据，并在持久性与写吞吐之间取舍。
2. 解释 xfs 的延迟分配为什么让大文件更连续、inode 为什么按需分配，以及 ext4 的 inode 数量为什么在 mkfs 那一刻定死。
3. 在 df -h 有余量而 df -i 满时，用可直接执行的命令序列定位到堆积小文件的具体目录。
4. 给出 du 与 df 不一致的三类根因与排查命令链，并说清稀疏文件属于哪一组"数字对不上"。
5. 计算 RAID 0/1/5/6/10 的容量利用率与随机写惩罚，解释数据库为什么几乎只用 RAID 10。
6. 说清报 IOPS 时必须同时给出哪几个口径，用 fio 复现可比的数字，并判断该先看 await 还是 %util。
7. 按三层结构排查 too many open files，并在磁盘写满时按正确顺序处置而不是乱删。

前置知识检查

13.1 ext4 与 xfs：三处分歧决定了选型

“xfs 更适合大文件"只是现象。两者的真正分歧只有三处：日志模式的设计、空间分配时机、inode 分配方式。

13.1.1 ext4 的三种日志模式：保证什么、放弃什么

ext4 的日志由 jbd2 实现，是环形日志。元数据（inode、目录项、块映射）永远先写日志再落最终位置——这是所有模式的共同点，区别只在数据怎么办。

writeback 的坏数据形态必须能描述清楚，这是分水岭：/etc/passwd 刚被缩短，尾部块被释放并分给新建的 secret.txt；若元数据事务先提交而数据块后写，此时掉电，重启后 secret.txt 的长度与块映射指向该块，内容却还是旧 /etc/passwd 的尾部——结构完整，fsck 也查不出，数据却是别的文件的残留。这就是 ordered 存在的唯一理由：它保证的不是数据进日志，而是顺序。

1
2
3

mount | grep ' / '                                  # 当前生效的模式在这里（如 data=ordered）
tune2fs -l /dev/sda1 | grep 'Default mount options' # 这是默认值，不是当前生效值
mount -o remount,data=writeback /                   # 在线切换，不需 umount

13.1.2 xfs 的延迟分配、预分配与在线扩容

延迟分配（delayed allocation, delalloc）把"分配哪些块"推迟到回写时刻。收益来自信息量：write 时只知道这一页，回写时能看到整个脏区间，于是一次分配出巨大的连续 extent，元数据条目数、碎片率与后续顺序读效率同时改善。ext4 默认也开 delalloc（nodelalloc 可关），xfs 的差别在更激进的投机预分配（speculative preallocation）：写入时预留 EOF 之外一段空间，避免多个写入者交错插进同一文件造成碎片。代价有两条：ENOSPC 会推迟到回写阶段才暴露，应用必须处理"之前写成功、之后报错"；预分配会让 df 的已用空间暂时大于 du 数出来的数据量，配额统计尤其容易被它误导。

1
2
3

growpart /dev/sda 3          # 先扩底层设备（分区 / LVM LV / 云盘），再让文件系统吃满
xfs_growfs -d /data          # xfs 只增不减：缩容只能备份重建
resize2fs /dev/sda3          # ext4 扩容可在线；缩小必须先 umount 并 fsck

大文件、高并发场景常选 xfs 的结构原因不是延迟分配，而是分配组（allocation group, AG）：空闲空间、inode、extent 都按 B+ 树组织并按 AG 分区，多个写入者落在不同 AG 上可并行修改各自的元数据；ext4 的块分配与组描述符在写者多、目录大时成为争用点。所以选型语境里的"高并发"指的是元数据操作的并行度，不是单个文件的大小。

13.1.3 inode 的两种分配哲学

ext4 的数字必须会心算，mke2fs 默认 bytes-per-inode = 16384：

1
2
3

2 TiB 的 ext4（mkfs 默认参数）
  inode 总数 = 2 TiB / 16 KiB = 2⁴¹ B / 2¹⁴ B = 2²⁷ = 134,217,728 ≈ 1.34 亿
  inode 表占用 = 1.34 亿 × 256 B = 2³⁵ B = 32 GiB   ← 固定吃掉，与存了多少文件无关

13.2 inode 耗尽：df -h 有空间而 df -i 满

2 TiB 的 ext4 上若文件平均只有 1 KB：inode 总量 1.34 亿，每个文件至少占一个 4 KiB 块，1.34 亿个文件需要约 512 GiB 数据——inode 先于空间耗尽，而此时 df -h 只显示约 27%。这就是"监控显示磁盘很空、写入却报 No space left on device“最常见的形态。

定位序列固定为"先确认维度，再逐层聚合”：

1
2
3
4
5
6
7

df -h; df -i                          # 第 1 步：必须同时看，否则会朝完全错误的方向排查
df -i / /var /data                    # 第 2 步：把范围从整机缩到某个挂载点
# 第 3 步：按目录聚合文件数。关键在 -xdev，不加就会跨挂载点、把别的文件系统算进来
find /var -xdev -type f -printf '%h\n' | sort | uniq -c | sort -rn | head -20
# 按 %h（目录）而不是 %p（完整路径）聚合：完整路径会把一个目录下的百万文件散成百万行
du --inodes -d1 /var/spool 2>/dev/null | sort -n | tail   # 第 4 步：下钻，只看数量不看大小
find /var/spool/clientmqueue -xdev -type f -mtime +7 | head  # 第 5 步：删之前确认能删

13.3 du 与 df 不一致：三类根因

两者的数据来源完全不同，这是所有不一致的总根源：df 读超级块里的全局计数器（statfs），统计已分配出去的块，不管这些块有没有名字；du 按名字遍历目录树，累加每个文件的 st_blocks。凡"有分配、无名字"或"有名字、看不见"的块，都只出现在 df 里。

完整命令链按"先量化差值、再定向、最后验证"推进：

1
2
3
4
5
6
7
8

df -h /data; du -xsh /data      # -x 不跨挂载点；du 明显小于 df 就先怀疑"有分配、无名字"
lsof -nP +L1 | sort -k7 -rn | head -20   # +L1 = 链接数小于 1；-n 避免 DNS 反解卡住
# lsof 不可用时的兜底：直接读内核暴露的 fd 符号链接
find /proc/[0-9]*/fd -lname '* (deleted)' -printf '%l\n' 2>/dev/null | sort | uniq -c | sort -rn | head
findmnt -o TARGET,SOURCE,FSTYPE -R /data  # 排除挂载点覆盖
# 想看被遮住的原目录里有什么，用 bind mount 换一个视角看同一个文件系统
mkdir -p /mnt/root && mount --bind / /mnt/root && du -sh /mnt/root/data; umount /mnt/root
tune2fs -l /dev/sda3 | grep -E 'Block count|Reserved block count'   # 最后才看保留块

处置已删除但仍被持有的文件有三种方式，代价不同：让持有进程重新打开（reload/kill -USR1，最安全）；重启进程（最彻底，有中断）；直接截断 : > /proc/<pid>/fd/<n>（立即生效，但只对普通文件有效，且若进程以固定偏移随机写而非追加写，截断会造成数据损坏——数据库数据文件绝不能这么干）。

13.4 挂载选项：每一次读都可能变成一次写

13.4.1 atime 的写放大链路

纯读变成写的链路是：read → file_accessed() 更新 inode->i_atime 并把 inode 标脏 → 回写时写入 inode，且 ordered 模式下这次元数据修改还要提交一次 jbd2 日志事务。放大倍率的准确口径是"每个 inode 每次回写一次"而非"每次读一次写"，因为同一 inode 的多次读会在内存里合并；但对每次读的都是不同 inode 的负载——静态资源服务、备份扫描、编译、find 遍历——两者等价：读一个文件就付一次随机元数据写加一次日志提交。

1
2
3

mount -o remount,noatime,nodiratime /data   # 在线改，不需 umount
# 第四列的最终形态：rw,noatime,nodiratime,errors=remount-ro,barrier=1
findmnt -o TARGET,OPTIONS /data             # 核对实际生效值，而不是 fstab 里写的值

13.4.2 sync 与 async、barrier 与 nobarrier

async（默认）让写只到 page cache 就返回，真实落盘由回写线程异步完成；-o sync 则让文件系统层面所有写同步完成，近似于给每个文件加 O_SYNC，吞吐直接退化为约 1 / 设备写延迟——对 L = 100 μs 的设备也只有约 10⁴ 次写/秒。需要单点同步语义时该用 per-file 的 O_SYNC/O_DSYNC 或 fsync，不要动整个挂载点，把整盘拖进同步写是典型的一处配置毁掉整个文件系统。

barrier（现代内核由块层 flush/FUA 实现）保证的是顺序：日志提交不能早于它描述的数据与元数据落介质。nobarrier 关掉这条保证后，设备易失性写缓存中的写可能乱序落盘，掉电后果不是"丢最后几笔"，而是文件系统结构可能不一致——这正是它与"丢数据"的区别。只有设备自带掉电保护（BBU、超级电容 + NAND，或本身不声明易失写缓存）时关屏障才安全；设备不支持 flush 时内核会打印 Disabling barriers, not supported by the underlying device，那属于设备能力不足而非配置选择。

errors=remount-ro 是 ext4 默认行为：检测到不一致就把文件系统重新挂载为只读，此后应用写失败并返回 EROFS。生产中"服务突然全变只读、进程没死、CPU 也不高"的第一嫌疑就是它，dmesg 里能找到 ext4 报错与 remount 记录；集群共享存储上更激进的取值是 errors=panic，用立即崩溃换取不一致状态不再扩散。

13.5 存储层次与 RAID：写惩罚是怎么算出来的

13.5.1 五个级别的四个维度

设成员盘数为 N、单盘容量 C、单盘随机 IOPS 为 I：

13.5.2 写惩罚的逐步推导

小随机写只改一个数据块，而校验必须基于整条条带重算，于是控制器被迫先读后写：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

RAID 5 修改一个 4 KiB 数据块 D0（同一条带内还有 D1、D2 与校验 P）

  P_new = P_old ⊕ D0_old ⊕ D0_new        ← 校验重算只需异或，CPU 不是瓶颈
  ① 读 D0_old  ② 读 P_old  ③ 写 D0_new  ④ 写 P_new
  为什么必须先读：校验按整条带算，不读旧值就无法只更新其中一个块
  ⟹ 4 次设备 I/O 换 1 次逻辑写，写惩罚 = 4
RAID 6：两个独立校验 P、Q（Reed-Solomon），读 D0_old/P_old/Q_old、写三者
  ⟹ 3 读 + 3 写，写惩罚 = 6
RAID 10：数据写两份镜像 ⟹ 2 次设备 I/O，写惩罚 = 2

整条带写（full-stripe write）是唯一例外：一次写覆盖条带内全部 N−1 个数据块时
无需读旧值，新校验可由新数据直接算出 ⟹ 写惩罚摊到每个数据块上接近 1。
这就是"RAID 5 顺序大块写不吃亏、只怕小随机写"的量化根因。

据此得到工程估算式 可用随机写 IOPS = N × I / 写惩罚。用 12 块 10K rpm SAS（I ≈ 150）算一遍：

1
2
3
4
5

RAID 5 : 12 × 150 / 4 = 450 IOPS   容量 11 × C
RAID 6 : 12 × 150 / 6 = 300 IOPS   容量 10 × C
RAID 10: 12 × 150 / 2 = 900 IOPS   容量  6 × C   ← 写 IOPS 最高，容量只有 RAID 5 的 55%
读不产生惩罚：数据块分布在所有成员盘上，正常读可让全部 N 块并行参与，
因此读吞吐近似随盘数线性增长（实际受条带大小与请求大小限制）。

13.5.3 JBOD 与 RAID 的取舍

JBOD（just a bunch of disks，直通模式）把每块盘独立交给上层，容量求和、无冗余。分布式存储（对象存储、HDFS、Ceph 一类）几乎一律选 JBOD：副本或纠删码已在软件层提供冗余，硬件层再做一次是双重浪费；RAID 组容量按最小盘计算，迫使盘规格统一；而且 RAID 控制器本身是单点，固件、缓存、电池任何一处出问题都是整组风险。RAID 的适用面反而是"单机内需要冗余、且对上层透明"的传统部署——数据库单机、老应用的裸机盘。

13.5.4 硬件 RAID 的写缓存与 BBU

带写回缓存（write-back cache）的阵列卡先写缓存就向主机确认，单次写延迟从"介质往返"降到"缓存写入"。前提是缓存内容掉电不丢，所以必须配电池备份单元（battery backup unit, BBU）或超级电容 + NAND 的闪存备份缓存。两个生产现象由此解释：电池失效时多数控制器自动切回写穿（write-through），性能骤降，这是"昨天还很快、今天突然慢"的一类原因；而在没有掉电保护的易失缓存上再配 nobarrier，是缓存丢失与乱序落盘的双重风险叠加。

13.5.5 为什么数据库几乎只用 RAID 10

四条理由按重要性排序。其一，写惩罚：随机写 IOPS 是 RAID 5 的 2 倍、RAID 6 的 3 倍，而 OLTP 的随机写占比极高，这笔差距直接决定能承载的 TPS。其二，重构代价与风险：RAID 5/6 重构要读整组所有盘的条带并重算校验，耗时与整组容量成正比，期间性能显著塌陷，且窗口内再坏一块就全丢；RAID 10 只需从镜像盘复制，耗时与单盘容量成正比，不影响其他盘组。其三，不可恢复读错误（unrecoverable read error, URE）：大容量盘上重构整组要读取天文数字的扇区，期间遇到一个无法纠正的读错误就会让 RAID 5 重构失败、整组不可用——这是"TB 级盘时代 RAID 5 不再被推荐"的标准论证。其四，RAID 5 的写洞（write hole）：掉电可能留下数据与校验不一致的条带，潜伏到下一次掉盘才暴露。唯一代价是容量利用率腰斩，这是可预算的成本，而前述四条都是不可控的风险。

13.6 IOPS 与吞吐量的口径

13.6.1 必须同时报的口径

量化关系来自 Little 定律的直接推论：Q = IOPS × L，即 IOPS = Q / L，而 吞吐量 = IOPS × 块大小。同一块盘，4 KiB 随机读 100 K IOPS 对应 400 MB/s；换成 1 MiB 顺序读，IOPS 可能只有 1 K 而带宽达到 1 GB/s。“能跑多少 IOPS"与"能跑多少 MB/s"是两个独立上限，不能互相换算。

13.6.2 fio 的关键参数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 随机读 IOPS 口径。在途请求总数 = iodepth × numjobs = 256，报数字必须一起给出
fio --name=randread --ioengine=libaio --direct=1 --rw=randread \
    --bs=4k --iodepth=32 --numjobs=8 --size=4G --runtime=60 --time_based \
    --filename=/data/fio.test --group_reporting --output-format=json
# 顺序带宽口径：1 MiB、队列深度 8、单任务，与上面相差数个数量级
fio --name=seqread --ioengine=libaio --direct=1 --rw=read \
    --bs=1M --iodepth=8 --numjobs=1 --size=16G --runtime=60 --time_based \
    --filename=/data/fio.test --group_reporting
# 持续写要够长：SLC 缓存几十秒就写满，--runtime=600 起步才能看到"掉速后"的性能
fio --name=sustained --ioengine=libaio --direct=1 --rw=randwrite \
    --bs=4k --iodepth=32 --numjobs=4 --size=8G --runtime=600 --time_based \
    --filename=/data/fio.test --group_reporting

13.6.3 iodepth 与 %util 的关系

%util 来自 /proc/diskstats 的 io_ticks，定义是"该设备至少有一个在途请求的时间占比”，它回答忙不忙，不回答还能不能更快。两者的关系由队列深度决定：

• 队列深度 1 的机械盘：一次只有一个在途请求，%util 到 100% 基本等于打满，此时 await ≈ 单次 I/O 时间。
• 队列深度 32 以上的 NVMe：控制器内部可并行处理上百个请求，%util 停在 100% 时设备可能仍有余量；真正的饱和信号是 aqu-sz（平均在途请求数）持续升到接近设备的最佳队列深度，并伴随 await 明显上升。

因此判断顺序是先看 await 与 aqu-sz，再用 %util 做旁证（%util 为什么不可靠见第 11 章 11.3 节）。await 高且 aqu-sz 高说明设备过载；await 高但 aqu-sz 低说明单次 I/O 本身就慢，与排队无关。

13.6.4 SSD 的写放大、GC 与 TRIM

NAND 只能按擦除块（erase block，通常数 MB）擦除、按页（通常 4_{16 KiB）写入，覆盖写必须先擦后写，而擦除单位远大于写单位，于是控制器必须做垃圾回收（garbage collection, GC）：把某擦除块里仍有效的页搬到新块再整块擦除，搬移量就是写放大（write amplification）：WA = 实际写入 NAND 的数据量 / 主机写入量。TRIM 的作用正在这条链的第一环：文件系统删除文件时不通知设备，设备就不知道那些逻辑块已失效，GC 会把它们当有效数据继续搬移，WA 随盘内碎片化上升，持续写性能与寿命同时下降。落地方式有两种：挂载 -o discard（每次删除立刻发 TRIM，给删除操作增加一次设备往返）或周期性 fstrim（推荐）。第二种衰减机制是 SLC 缓存：消费级 SSD 把一部分 TLC/QLC 当 SLC 用吸收突发写，缓存写满后速度落到原生水平，可能差 5}10 倍——这就是持续写测试必须跑够时长的原因。

1
2

fstrim -av                                   # 定期执行并观察各挂载点回收量
smartctl -a /dev/nvme0 | grep -Ei 'Percentage Used|Data Units Written|Available Spare'

13.7 谁在读写：从聚合指标到单次 I/O

1
2
3

biosnoop -d nvme0n1     # 一句话看"谁在读写、延迟多少"：pid、进程名、扇区、字节、延迟一应俱全
biosnoop -Q             # 延迟口径改为"从进入块层排队算起"，含排队等待
blktrace -d /dev/nvme0n1 -o trace -w 10 && btt -i trace -o trace.btt   # 需要延迟分布时

日常顺序是”iostat 定位设备 → iotop 定位进程 → biosnoop 确认单次 I/O 与延迟 → 需要 P99 分布才上 blktrace"，判断流程可固化成下图：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

现象：应用变慢，iostat 显示某块盘 await 升高
  ├─① 先看 await 与 aqu-sz（不是 %util）
  │    await 高 + aqu-sz 高  → 设备真的过载 ─────────────────▶ ②
  │    await 高 + aqu-sz 低  → 单次 I/O 本身就慢（掉速、介质错误
  │                            重试、被限流、后端抖动）───────▶ ③
  │    await 低 + %util 100% → 浅队列设备正常打满，不构成瓶颈证据 → 停止
  ├─② 找"谁"：iotop -oP 定位进程 → biosnoop -Q 看单次 I/O 与延迟；
  │    再分是"量"（并发请求数超设备能力 → 限流/降并发/加盘）还是
  │    "质"（SSD 磨损与持续写掉速、RAID 降级或重构、写缓存退回
  │           write-through、网络存储抖动）
  └─③ 需要 P99/P999 时上 blktrace + btt；不要在秒均值上做长尾结论

13.8 文件描述符与句柄：三层排查

too many open files 必须按三层定位：

区分"配置不足"与"泄漏"的唯一可靠判据是时间维度：配置不足在稳态水平上下波动、随时可复现；泄漏只涨不跌，或在某个操作后阶梯式上升。前者调大上限（注意 systemd 与容器运行时的配置会覆盖 shell 设置），后者必须修代码——调大上限只会让它以更难看的方式失败，fd 表占用大量内核内存，最终 OOM 或全系统 ENFILE。

1
2
3
4
5
6
7
8

lsof -p 12345 -n | awk '{print $5}' | sort | uniq -c | sort -rn   # 按 fd 类型看构成
lsof -p 12345 -n +L1        # 该进程持有的已删除文件
lsof -i :8080; lsof -i @10.0.0.5 -nP    # 谁占着端口、谁连着某台对端
lsof +d /data/logs          # 只看这一层目录（快）
lsof +D /data/logs          # 递归整棵子树（大目录上极慢，慎用）
fuser -v /data/app.log      # 谁占用了这个文件
fuser -vm /data             # 该挂载点上所有使用者，umount 报 busy 时必用
fuser -n tcp 8080           # 不加 -v 时输出的是 pid，容易被看错

Java 服务的 fd 泄漏按指向物分类：指向 .jar 查类加载器与未关闭的 JarFile；指向 socket 查客户端连接池与未关闭的响应体（见第 18 章 18.2 节）；指向管道查未回收的子进程；表现为 anon_inode 的则是 epoll 实例、eventfd、timerfd、inotify 这类对象泄漏（fd 三层结构见第 7 章 7.1 节）。

13.9 磁盘满的紧急处置顺序

顺序本身就是考点。先不要猜是"大文件"还是"已删除文件"，用两条命令在几秒内定向：df -h 与 df -i 判断是块满还是 inode 满；du -xsh 与 df 对比判断空间是"有名字的"还是"无名字的"。这一步决定后面所有工作的方向。

1
2
3
4
5
6
7
8

df -h /data; df -i /data     # ① 判断维度：块 vs inode，两者必须同时看
du -xsh /data                # ② 判断有无名字：接近 df 去找大文件，远小于 df 去找已删除文件
# ③ 情况 A（du ≈ df）：逐层下钻，先删可再生的
du -x -d1 /data | sort -h | tail -10
du -x -d1 /data/logs | sort -h | tail -10    # 命中目录后继续下钻，直到定位到具体文件
# ④ 情况 B（du << df）：找持有者，让进程重开或重启后再删
lsof -nP +L1 | sort -k7 -rn | head -20
df -h /data                  # ⑤ 释放后必须回验，否则等于没做

处置的取舍原则：先删可再生的（日志、缓存、临时文件、core 转储、包管理器缓存），再考虑压缩或迁移；数据库数据文件、/etc 下的配置、正在写的 WAL 绝不能擅自 truncate；不要在满盘上跑无过滤的 find / 全盘遍历，它会加剧元数据与 I/O 压力，让本来还能响应的服务雪崩。

13.9.1 日志轮转失败导致的写满

logrotate 默认用 create 模式：把 app.log 改名为 app.log.1，再创建新的空 app.log，然后靠 postrotate 里的信号让应用重新打开日志。如果应用没有实现 reopen（或信号发错、进程名匹配不到），它会继续往已经改名的 app.log.1 里写——空间永不释放，而新文件一直是 0 字节，这是最典型的"轮转配置看起来正确、盘却一直满"的形态。

1
2
3

ls -l /var/log/app/app.log*     # 症状：.1 持续增长，而当前日志一直是 0
lsof -nP /var/log/app/app.log.1 # 确认是谁还在写旧 inode
grep -A5 -E 'postrotate|copytruncate|create' /etc/logrotate.d/app  # 检查信号与进程匹配

两条修法各有代价：让应用重新打开日志（首选，无丢失窗口，需要应用支持）；改用 copytruncate（应用无需配合，但复制与截断之间的写入会丢失，且对大流量文件会额外产生一次全量拷贝）。另外三类常见来源也要能一眼认出：systemd-journald（journalctl --disk-usage 查看，SystemMaxUse 限制，journalctl --vacuum-size=1G 应急）；容器日志（Docker 默认 json-file 驱动不限制大小，需在 daemon 配置里设 max-size/max-file，存量容器要重建才生效）；内核 core dump 与崩溃转储目录。

本章小结

自测题

Q1（计算）一个 2 TiB 的 ext4 按 mkfs 默认参数（每 16 KiB 一个 inode，inode 大小 256 B）创建，inode 总数与 inode 表占用空间分别是多少？若其上存了 800 万个平均 1 KB 的小文件，df -h 与 df -i 各显示什么？要多少个这种文件才会把 inode 用尽，届时空间用了多少？

Q2（辨析）df -h 显示还有空闲空间，应用写日志却报 No space left on device。请给出至少三个不同根因，并说明各自的排除命令。

Q3（计算）12 块 10K rpm SAS 盘，单盘随机 IOPS 约 150，单盘容量 1.8 TB。分别计算 RAID 5、RAID 6、RAID 10 的可用随机写 IOPS 与可用容量，并说明一个 OLTP 数据库该选哪个、代价是什么。

Q4（设计）一台机器 df -h /data 显示已用 900 GB，而 du -xsh /data 只有 30 GB。给出完整排查步骤、每一步的预期输出形态，并指出哪些"常见原因"在这个场景里可以被排除。

Q5（推导）为什么 noatime 值得开？请从"一次读如何变成一次写"的链路推导，说明 relatime 与 noatime 的差别，并解释为什么 nodiratime 与 noatime 同时给出时是冗余的。

面试高频问题与陷阱

延伸阅读

• man 5 ext4：三种 data= 模式的权威描述，含 writeback 数据暴露风险的原话。
• man 8 mkfs.xfs、man 8 xfs_growfs、man 8 xfs_info：分配组、imaxpct、投机预分配与在线扩容参数。
• man 8 mke2fs、man 8 tune2fs、man 8 resize2fs：bytes-per-inode/-N、保留块比例、离线缩容的前提。
• man 8 mount：noatime/relatime/nodiratime、sync、barrier、errors=、discard 的逐条语义。
• man 8 lsof、man 1 fuser：+L1、+d 与 +D、-v 与 -m 的行为差异。
• man 1 fio 与 fio 官方 HOWTO：--rw/--bs/--iodepth/--numjobs/--direct/--ramp_time 的含义。
• Linux 内核文档 Documentation/admin-guide/blockdev/ 与 Documentation/filesystems/：io_ticks 与 %util 的来源、文件系统挂载选项说明。
• 第 7 章 7.1~7.3 节（fd 三层结构与 dentry 缓存）、第 9 章 9.9 节（块层栈与 fsync）、第 11 章 11.3 节（%util 为什么不可靠）、第 12 章 12.2 节（脏页回写）构成本章的前置与后续。