第8章 磁盘与文件系统

I/O 全栈追踪

章节导读

存储是服务器中最慢的部件：NVMe SSD 的随机读延迟约 20-100 微秒，SATA SSD 约 100-500 微秒，HDD 约 5-10 毫秒，而内存访问是 100 纳秒——从内存到 HDD 跨越了五个数量级。这个鸿沟决定了 I/O 分析的核心命题：应用的数据请求到底走了哪条路径、在每一层花了多少时间、瓶颈在哪里。本章沿着 Linux I/O 栈自顶向下建立完整的追踪体系：VFS → 文件系统 → 页缓存 → 块层 → 设备驱动 → 物理设备。

先走一遍 I/O 栈的完整路径。应用调用 read()：进入 VFS（虚拟文件系统层，统一接口），VFS 查页缓存——命中则直接拷贝返回（零磁盘 I/O，微秒级）；未命中则触发文件系统（ext4/xfs/btrfs）的读路径，文件系统把逻辑偏移翻译成块设备扇区，构造 bio（块 I/O 的基本单位）提交给块层。块层做 I/O 调度（合并、排序、多队列分发——blk-mq 架构下每 CPU 一个软件队列，映射到设备的硬件队列），bio 变成 request 下发驱动，驱动通过 NVMe/AHCI 接口提交给设备。设备完成后触发中断（软中断 BLOCK 处理完成），层层回调通知应用。写路径更复杂：write() 只是把数据拷入页缓存并标记脏页（微秒级返回！），真正的磁盘写由回写机制异步完成——pdflush/kworker 线程按策略（脏页比例阈值、时间阈值）批量刷盘，fsync/fdatasync 强制同步刷盘。理解这个异步性是存储分析的关键：write 延迟低不代表磁盘快，只代表数据还在缓存里；真正的持久化延迟要看回写和 fsync。

BPF 工具在这条路径的每一层都有观测点。块层：biosnoop（逐 I/O 明细）、biolatency（延迟直方图）、biotop（I/O 排行）——它们追踪 request 的生命周期，测量 Q2C（入队到完成）、Q2D（入队到下发）、D2C（下发到完成，即设备时间）三段延迟，这个分解直接定位拥堵层：Q2D 大 = 内核队列积压（调度器或设备队列深度问题），D2C 大 = 设备慢。文件系统层：ext4slower/xfsslower/btrfsslower 追踪超过阈值的文件系统操作（慢操作明细），ext4dist/xfsdist 输出操作延迟直方图，fileslower 在 VFS 层追踪慢文件读写。VFS 层：vfsstat（读写操作计数）、vfscount（调用统计）。页缓存层：cachestat/cachetop（第 7 章已讲）。回写层：BPF 可以追踪 writeback 事件和脏页统计。这套分层工具对应分层排查法：应用喊慢 → 先分账（是读慢还是写慢？同步还是异步？）→ 文件系统层直方图（ext4dist）确认延迟量级 → 块层分解（biolatency -Q vs -D）定位队列还是设备 → biosnoop 抓明细看 I/O 特征（大小、类型、进程）→ 设备层 iostat/smartctl 确认硬件。

I/O 模式分析是解读数据的钥匙。随机 vs 顺序：HDD 上差异巨大（随机 5-10ms vs 顺序 0.1ms/IO 摊薄），SSD 上差异缩小但仍存在（随机读受 FTL 映射和队列深度影响）；读 vs 写：写有页缓存和回写的缓冲（延迟被隐藏），读未命中直接暴露设备延迟；同步 vs 异步：O_DIRECT 绕过页缓存（数据库的标准姿势，延迟真实反映设备），buffered I/O 经过缓存（延迟分布双峰：命中微秒、未命中毫秒）。biolatency -F 按标志分解、biosnoop 的类型列直接给出这些维度。一个经典的误诊案例：监控显示"磁盘延迟 50ms"，实际是 HDD 上随机小 I/O 的正常表现，应用真正的问题是 I/O 模式（该顺序的做成了随机、该批量的做成了逐个）——工具给你延迟数字，模式分析告诉你数字是否正常。

预读（readahead）与回写（writeback）是内核的两个智能机制，也是两个常见的性能陷阱。预读：顺序读触发内核提前读取后续页面（/sys/block/sda/queue/read_ahead_kb 控制），对顺序负载是巨大加速，对随机负载是纯浪费（预读的页从未被使用，白白消耗带宽和缓存）——数据库随机读场景调小预读是标准调优。回写：脏页由 /proc/sys/vm/dirty_ratio（进程被强制同步回写的阈值）和 dirty_background_ratio（后台回写启动阈值）控制，配置不当的后果：dirty_ratio 过高导致脏页堆积，某进程触发同步回写时被卡住数百毫秒（写延迟毛刺的经典根因）；过低导致回写过于频繁、I/O 碎片化。BPF 追踪回写行为（balance_dirty_pages、writeback 相关 tracepoint）能把"写延迟毛刺"与"脏页水位"直接关联。

存储性能瓶颈定位的方法论总结：USE 方法在存储维度的展开——利用率（iostat 的 %util，注意 NVMe 多队列下 %util 失真：100% 不代表饱和）、饱和度（队列深度 avgqu-sz、await 长尾、biolatency 分布）、错误（dmesg 的 I/O error、smartctl 健康度、文件系统只读重挂载事件）。BPF 的独特贡献是"延迟分解"和"进程归因"：传统 iostat 只有设备级聚合，BPF 能回答"这个 50ms 的 I/O 是哪个进程哪个文件发起的、在内核哪一层花掉了"——这是从设备视角到应用视角的跨越，也是存储排查从猜测变成实证的关键。

核心概念

• biosnoop
• biolatency
• 块层
• VFS
• 文件系统追踪
• I/O 调度
• 回写

要点精析

【Linux I/O 栈全景与追踪点地图】完整的 I/O 栈及每层的 BPF 追踪点：(1) 应用层——系统调用 tracepoint（sys_enter_read/write/pread/pwrite），工具 trace、syscount；(2) VFS 层——vfs_read/vfs_write 等函数（kprobe），工具 vfsstat、fileslower、filetop；(3) 文件系统层——ext4_file_read_iter、xfs_file_write_iter 等（kprobe）或 fs tracepoint，工具 ext4dist/ext4slower、xfsdist/xfsslower、btrfsdist；(4) 页缓存层——add_to_page_cache、mark_page_accessed（kprobe），工具 cachestat；(5) 块层——block tracepoint 家族（block_rq_insert/issue/complete、block_bio_queue），工具 biosnoop、biolatency、biotop；(6) 驱动/设备层——nvme tracepoint、scsi tracepoint，工具较少（iostat 的底层）。每层测量的"延迟"含义不同：VFS 层延迟包含页缓存查找（命中时几乎为零）；块层延迟只覆盖 bio 提交到完成（缓存命中的 I/O 根本不进块层！）；设备延迟只是 D2C 段。排查时先明确"你测的是哪一层的延迟"——ext4dist 显示 100μs 而 biolatency 显示 8ms 不矛盾：前者大部分命中缓存，后者只统计真正下盘的 I/O。这个分层视角是存储分析的地图，迷路时回到这张图。

【biosnoop 深入：逐 I/O 的显微镜】biosnoop 输出每个块 I/O：TIME(ms)、COMM/PID/DISK/T(R|W)/SECTOR/BYTES/LAT(ms)。延迟列默认是 Q2C（入队到完成），-Q 显示分解的 Q2D 和 D2C。PID/COMM 的归属陷阱（重点）：块 I/O 是异步的——应用提交 read 后可能睡眠，I/O 完成时的"当前进程"上下文是完成中断处理者或 kworker，因此 biosnoop 显示的进程可能不是发起者！同步 direct I/O 的归属较准确（应用线程等待完成），buffered I/O 的预读和回写归属到 kworker/kswapd。想准确归因发起进程，用 fileslower（VFS 层追踪，进程上下文准确）或 stackcount 抓提交栈。实战用法：(1) 找慢 I/O——biosnoop -m 10（只显示 >10ms 的，新版本支持）或 bpftrace 阈值过滤，输出慢 I/O 的大小/类型/位置特征；(2) I/O 模式画像——观察 SECTOR 序列判断顺序性、BYTES 分布判断 I/O 大小、R/W 比例；(3) 队列分析——Q2D 大说明块层拥堵（调度器队列积压、设备队列满），D2C 大说明设备慢。开销：每 I/O 一条 perf 事件，NVMe 高 IOPS（50 万+）下输出通道会饱和，生产环境限时运行或加阈值过滤。

【biolatency 深入：延迟分布的分层解读】biolatency 的选项组合构成延迟分解矩阵：默认（Q2C 全程）、-D（D2C 设备时间）、-Q（Q2D+D2C 分解显示）、-F（按 I/O 标志分解：读/写/同步/元数据/flush）、-O（按磁盘分解）、-m/-u（单位切换）。解读决策树：(1) Q2C 长尾但 D2C 正常 → 内核队列拥堵：查 avgqu-sz（iostat）、I/O 调度器（mq-deadline/bfq/none，NVMe 默认 none）、设备队列深度（nr_requests）、是否有大量 flush（-F 看 FLUSH 标志的延迟——flush 强制缓存刷盘，是数据库提交的关键路径，慢 flush 拖垮事务）；(2) D2C 长尾 → 设备问题：SSD 的 GC（内部垃圾回收造成周期性慢 I/O，smartctl 看磨损和 GC 计数）、HDD 的机械寻道、RAID 卡缓存策略、虚拟化层的后端存储抖动（云盘的 burst 额度耗尽是经典案例）；(3) 读延迟正常写延迟长尾 → 回写风暴或设备写缓存问题；(4) 双峰分布 → 两种设备混用（RAID 中有慢盘）或缓存命中/未命中混合（-D 模式排除缓存影响）。biolatency 与 iostat await 的关系：await 是平均值（掩盖长尾），biolatency 是完整分布——平均值 2ms 可能是"全部 2ms"或"99% 是 0.5ms + 1% 是 150ms"，后者对 P99 业务是灾难。这就是 Gregg 强调"直方图优于平均值"的存储场景实证。

【文件系统层追踪：ext4dist、xfsslower 与 fileslower】文件系统工具分两类：dist 类输出延迟直方图（ext4dist/xfsdist/btrfsdist 按操作类型 read/write/open/fsync 分解），slower 类输出超过阈值的慢操作明细（ext4slower 10 显示 >10ms 的 ext4 操作，含文件路径！）。fileslower 在 VFS 层工作（覆盖所有文件系统），fileslower -b 只追踪 buffered I/O。slower 类工具的独特价值是"文件路径归因"——块层工具（biosnoop）只有扇区号，文件系统工具能告诉你慢操作发生在哪个文件上，这是从"设备慢"到"谁的文件慢"的关键一步。典型排查流：应用报写延迟毛刺 → ext4slower 10 抓到毛刺时刻的慢写及文件路径 → 发现是日志文件的写 → 结合 biolatency -F 确认是 flush 慢（日志用 O_SYNC 或频繁 fsync）→ 解决方案（批量提交、异步日志、调整 fsync 策略）。fsync 专项：ext4 的 fsync 路径涉及日志提交（jbd2），BPF 追踪 vfs_fsync_range 耗时（第 4 章示例3的脚本）+ jbd2 相关事件可以分解 fsync 的时间构成。注意：文件系统工具的 kprobe 挂载点随内核版本变化较大（ext4_file_read_iter 等函数签名演进），BCC 工具持续适配，手写脚本要按内核版本调整——这是 CO-RE 价值的最直接体现场景。

【I/O 调度器与多队列块层（blk-mq）】现代内核的块层是 blk-mq 架构：每 CPU 一个软件队列（software queue），映射到设备的硬件队列（NVMe 天然多队列，SATA 通过 libata 模拟）。I/O 调度器选项：none（不排序不合并，NVMe 高性能设备的推荐——设备内部有自己的调度）、mq-deadline（按读写分队列 + 截止时间防饿死，通用默认）、bfq（带宽公平队列，桌面/混合负载的公平性优先）、kyber（延迟目标驱动，数据中心混合负载）。调度器影响 biolatency 的 Q2D 段：调度器排队、合并（相邻扇区的 I/O 合并成大 I/O——HDD 受益巨大，SSD 收益小）、限流。分析工具：iostat 的 avgqu-sz（平均队列深度）、/sys/block/sda/queue/scheduler（当前调度器）、biosnoop -Q 的 Q2D 分解。调优场景：(1) NVMe 数据库服务器用 none（应用自己管理 I/O 模式，内核排序是多余开销）；(2) HDD 用 mq-deadline（合并和排序对机械盘至关重要）；(3) 混合负载（延迟敏感 + 吞吐型共存）用 bfq 或 cgroup io 控制器做隔离。cgroup v2 的 io.max（带宽/IOPS 限制）和 io.latency（延迟保护）是容器环境的 I/O QoS 工具——第 10 章展开。理解调度器才能解释"为什么 Q2D 有时很大"：不是设备慢，是内核在排队、合并、或执行公平策略。

【预读与回写：内核智能机制的追踪与调优】预读（readahead）：顺序读检测触发，内核提前异步读取后续页面。参数 /sys/block/sda/queue/read_ahead_kb（默认 128KB）。追踪：block tracepoint 的预读标志（REQ_RAHEAD），biosnoop 输出中可识别；readahead 系统调用（posix_fadvise WILLNEED 触发）可用 tracepoint 追踪。调优：顺序大文件扫描（备份、分析）调大预读加速；随机读负载（数据库）调小到 0-16KB 避免浪费——预读的页未被使用就是纯损耗（带宽 + 缓存污染）。回写（writeback）：脏页刷盘机制。参数体系：dirty_background_ratio（默认 10%，超过后 kworker 异步回写）、dirty_ratio（默认 20%，超过后写入进程被强制同步回写——写延迟毛刺的元凶）、dirty_expire_centisecs（脏页最长存活 30 秒）、dirty_writeback_centisecs（回写线程唤醒周期 5 秒）。追踪：balance_dirty_pages（kprobe，进程被限流的入口）、writeback tracepoint 家族（writeback_dirty_page、writeback_start 等）、ext4/xfs 的 jbd2 日志事件。经典问题："写延迟周期性尖峰"→ BPF 追踪 balance_dirty_pages 发现尖峰时刻大量进程进入同步回写 → dirty_ratio 过高导致脏页堆积后集中清算 → 调低 dirty_background_ratio 让回写更早更平滑。容器注意：cgroup v2 的 memory.high 触发回收时也会回写脏页，与全局回写机制叠加。

【I/O 模式分析：随机/顺序、大小、队列深度】I/O 性能强烈依赖模式，分析维度：(1) 随机 vs 顺序——biosnoop 的 SECTOR 列序列判断（连续递增 = 顺序），HDD 上顺序 I/O 吞吐可达随机的 100 倍；(2) I/O 大小——BYTES 分布直方图（bpftrace hist(args->bytes)），4KB 随机读是数据库模式，1MB 顺序写是备份模式，大小决定设备效率（SSD 的内部并行度需要足够大的 I/O 或足够深的队列才能发挥）；(3) 队列深度——iodepth（应用并发提交的 I/O 数），SSD 的延迟-吞吐曲线随队列深度改善（内部多通道并行），单线程 iodepth=1 的 4KB 随机读只能发挥 NVMe 性能的 10%——fio 测试必须扫队列深度维度；(4) 读写比例与混合模式——SSD 的写有额外成本（FTL 映射更新、GC），混合负载延迟高于纯读。工具链：fio 是模式化负载生成器（--rw=randread --bs=4k --iodepth=32 --numjobs=4 精确构造模式），biosnoop/biolatency 分析真实负载的模式特征。方法论：拿到"磁盘慢"的抱怨，先画像真实 I/O 模式（大小分布、随机度、队列深度、读写比），再用 fio 在相同模式下测设备基线——真实延迟 vs 基线延迟的差距才是"问题"，很多"磁盘慢"其实是"模式差"（应用做了大量低效小随机 I/O，设备无辜）。

【O_DIRECT 与 buffered I/O：两条路径的分析差异】buffered I/O（默认）：读写经过页缓存，读命中零设备 I/O，写先进缓存后异步回写——延迟低且平滑，但数据不立即持久（fsync 才保证），且缓存行为引入不确定性（命中率波动 = 延迟波动）。O_DIRECT：绕过页缓存直达设备（要求对齐：偏移和大小按扇区/块对齐），延迟真实反映设备，无缓存污染——数据库（InnoDB、PostgreSQL 部分场景）的标准选择（自己管理缓冲池比内核页缓存更高效）。分析差异：buffered 负载的 biolatency 只包含未命中部分（命中不进块层），ext4dist 包含全部（命中 + 未命中）——两个工具的直方图形状可能完全不同，这是正常的分层语义差异；O_DIRECT 负载则两层一致（全部进块层）。fsync 分析专题：即使 buffered 写延迟低，fsync 会暴露真实的持久化成本——fsync 延迟 = 刷脏页 + 刷文件系统日志（ext4 的 jbd2 提交）+ 设备 flush 命令（写缓存刷盘）。BPF 分解：追踪 vfs_fsync_range 总时长 + ext4_sync_file 内部事件 + 块层 FLUSH 标志的 I/O 延迟。数据库提交延迟优化（组提交 group commit、fsync 合并）的效果验证就靠这套分解。云存储注意：某些云盘的"写缓存"语义与物理设备不同（分布式存储的持久化确认机制），fsync 延迟特征需要重新建立基线。

【存储虚拟化与云环境的 I/O 分析】云环境的 I/O 栈比物理机多几层：guest 文件系统 → guest 块层 → virtio 驱动 → hypervisor（QEMU/vhost）→ 宿主机文件系统/块层 → 网络存储协议（NVMe-oF、EBS 类分布式存储）→ 物理设备。每层都引入延迟和排队。分析要点：(1) guest 内 biolatency 测的是"guest 块层到虚拟设备完成"，包含 hypervisor 和后端存储的全部延迟——D2C 长尾的根因可能在宿主机或存储网络，guest 内看不到；(2) 云盘的 burst 机制——突发性能额度（如 AWS gp3 的基线 IOPS + burst 额度）耗尽后性能骤降到基线，表现为"周期性变慢"，监控云厂商的 burst 余额指标；(3) IOPS/带宽限流——云盘有配额（如 3000 IOPS 上限），达到上限后延迟陡增（排队在虚拟化层），guest 内 avgqu-sz 不一定反映（排队在 guest 之外）；(4) 多挂载/共享存储的一致性开销。BPF 的角色：guest 内用全套工具画像应用侧行为（模式、延迟分布、进程归因），与云监控（设备级 IOPS/延迟/配额使用）交叉对照——两侧数据的"夹逼"定位问题层：guest 延迟高 + 云监控延迟高 = 存储后端问题；guest 延迟高 + 云监控正常 = guest 内排队（调度器、队列深度、CPU 不足导致完成处理延迟）。虚拟化层的深入（vhost 线程、宿主机块层）需要宿主机权限，用同样的 BPF 工具在宿主机分析。

【存储错误与健康度追踪】I/O 错误链：设备返回错误（NVMe status、SCSI sense）→ 驱动重试（某些错误可恢复）→ 重试失败上报块层 → 文件系统收到错误（ext4 默认 errors=remount-ro，只读重挂载保护数据！）→ 应用收到 EIO。追踪手段：(1) biosnoop 的 ERR 列（新版本显示错误）；(2) bpftrace 挂 block_rq_complete tracepoint 过滤 args->error 非零事件——错误 I/O 的实时告警源；(3) dmesg 的 I/O error 记录（blk_update_request: I/O error, dev sda, sector 12345）；(4) smartctl -a 的健康度（Reallocated_Sector_Ct、Current_Pending_Sector、NVMe 的 percentage_used 和 media_errors）——预测性指标，pending sector 增长即换盘信号；(5) /sys/block/sda/stat 的第 10 列（io_ticks）与错误计数。文件系统只读重挂载是生产事故的高发点：一块盘的瞬时错误触发 ext4 只读保护，应用全部写失败——事后分析用 BPF 记录的错误 I/O 时间线（哪个扇区、什么操作、重试了几次）区分"设备真故障"与"链路瞬时抖动"（HBA、线缆、虚拟化层）。RAID 场景：mdadm 的 repair 周期、RAID 卡的重建（rebuild）会造成持续的性能降级，追踪设备级延迟分布（biolatency -O 按盘分解）能发现 RAID 中的"慢盘"（latency outlier，一块盘拖慢整个阵列——RAID 的写延迟由最慢成员决定）。

代码示例

/* 示例1：biosnoop 的延迟分解与慢 I/O 定位 */
sudo /usr/share/bcc/tools/biosnoop -Q
/* TIME(ms)  COMM    PID   DISK  T SECTOR    BYTES  Q2D(ms) D2C(ms)
   0.000    mysqld  2233  sda   R 8823401   16384   0.02    8.41
   1.203    kworker 1523  sda   W 1029384   131072  45.20   2.10   <- Q2D 大：队列拥堵
*/
/* bpftrace 版：只显示超过 10ms 的 I/O */
sudo bpftrace -e '
tracepoint:block:block_rq_complete {
    $lat = (nsecs - @start[args->sector]) / 1000000;
    if ($lat > 10) { printf("slow io: sector %d len %d lat %d ms\n", args->sector, args->nr_sector * 512, $lat); }
    delete(@start[args->sector]);
}
tracepoint:block:block_rq_issue { @start[args->sector] = nsecs; }'

biosnoop -Q 的三列延迟分解是存储排查的核心数据。上面两条输出展示了两种截然不同的问题：mysqld 的读 I/O，Q2D 只有 0.02ms（内核队列畅通）但 D2C 8.41ms（设备慢）——16KB 的读花 8ms，对 SSD 是异常（正常 <0.5ms），对 HDD 是正常寻道时间，先确认设备类型再下结论；kworker 的写 I/O，Q2D 45.2ms（在块层队列里排了 45ms！）但 D2C 2.1ms（设备本身不慢）——这是队列拥堵：131KB 的大写 I/O 由回写线程发起，排队说明提交速率超过设备处理能力，查 iostat 的 avgqu-sz 和 %util、考虑 I/O 调度器设置或 cgroup 限流保护。bpftrace 版本展示自定义阈值过滤——注意它用 sector 做配对键有缺陷（同扇区并发 I/O 会串扰，生产用 request 指针或 dev+sector 复合键，BCC 工具的实现更严谨）。解读心法：Q2D 问题往内核查（调度器、队列深度、限流），D2C 问题往设备查（硬件、固件、虚拟化后端、云配额）。

/* 示例2：biolatency 分层对比——定位延迟发生的层 */
sudo /usr/share/bcc/tools/biolatency -D 10 1   /* 仅设备时间 */
sudo /usr/share/bcc/tools/biolatency -Q 10 1   /* 队列+设备分解 */
sudo /usr/share/bcc/tools/biolatency -F 10 1   /* 按 I/O 标志分解 */
/* -F 输出示例：
Read = 1
usecs : count  distribution
  64 -> 127 : 8932 |******************************|
Write = 1
usecs : count  distribution
  1K -> 2K  : 203  |******************************|   <- 写比读慢一个量级
Flush = 1
msecs : count  distribution
  16 -> 31  : 45   |******************************|   <- flush 高达 16-31ms！
*/

-F 按标志分解的输出信息量巨大。上面的数据讲了一个数据库存储的故事：读延迟主峰 64-127μs（健康的 SSD 随机读）；写延迟主峰 1-2ms（比读慢一个量级——可能是设备写缓存策略、SSD 内部 GC、或 RAID 写惩罚）；最刺眼的是 Flush：16-31ms！flush 是强制设备缓存刷盘的操作，数据库每次事务提交（fsync）都会触发——16ms 的 flush 意味着事务提交延迟的下限就是 16ms，TPS 上限被锁死在 60 左右。排查方向：(1) RAID 卡缓存策略——write-back 需要 BBU（电池）正常，BBU 失效会退化为 write-through，flush 成本暴增（storcli/MegaCli 查缓存状态）；(2) 设备写缓存——hdparm -W 查看，某些云盘/虚拟磁盘的 flush 语义映射到分布式存储的多数派确认（天然毫秒级）；(3) flush 频率——应用是否每事务都 fsync（组提交可以摊薄）。这个案例展示了标志分解的价值：总延迟直方图里 flush 事件占比小（45 个 vs 读 8932 个）几乎不可见，但对事务型应用它是决定性的延迟源。分析存储问题永远要问：什么类型的 I/O、多大、多频繁、延迟分布如何——biolatency -F 一次回答前三个维度的延迟。

/* 示例3：ext4slower——带文件路径的慢操作追踪 */
sudo /usr/share/bcc/tools/ext4slower 10
/* Tracing ext4 operations slower than 10 ms
TIME     COMM    PID    T BYTES OFF_K  LAT(ms) FILENAME
10:23:01 mysqld  2233   R 16384 102400   45.20 ibdata1
10:23:02 app     3021   W 4096  8821     12.30 orders.log
*/
sudo /usr/share/bcc/tools/fileslower -b 10   /* VFS 层，只追踪 buffered I/O */

ext4slower 的独特价值是 FILENAME 列——块层工具只有扇区号，把扇区反查到文件需要 debugfs 手工操作，而文件系统层工具直接给出文件名。上面的输出立即揭示两个问题：mysqld 读 ibdata1（InnoDB 系统表空间）慢 45ms——结合 biosnoop 的 Q2D 分解确认是队列还是设备；app 写 orders.log 慢 12ms——日志写入慢，可能是 fsync 策略或回写压力。参数说明：10 是毫秒阈值（ext4slower 0 追踪所有操作，输出量大但可做完整延迟画像）；T 列 R/W 是操作类型；BYTES 是操作大小；OFF_K 是文件内偏移（KB）——偏移序列还能判断访问模式（递增 = 顺序）。fileslower 在 VFS 层（vfs_read/vfs_write 的入口出口配对）工作，覆盖所有文件系统且只看到应用发起的操作（回写、预读不可见——它们在文件系统层以下发生）；-b 只追踪 buffered、-d 只追踪 direct。工具选择：想知道"应用视角哪个文件慢"用 fileslower/ext4slower；想知道"设备视角 I/O 行为"用 biosnoop/biolatency；两层数据的时间戳对齐分析（同一时刻的慢操作在两层的表现）是定位"延迟产生层"的终极方法。

/* 示例4：I/O 模式画像——大小分布与随机度 */
sudo bpftrace -e '
tracepoint:block:block_rq_issue {
    @size[args->nr_sector * 512] = count();          /* I/O 大小分布 */
    @rw[args->rwbs] = count();                        /* 读写类型（RWBS 标志字符串） */
    @sectors = hist(args->sector);                    /* 扇区分布（粗略随机度） */
}'
/* 输出示例：
@size[4096]: 8923      <- 4KB 主导：数据库随机 I/O 模式
@size[131072]: 203     <- 128KB：预读或回写的大 I/O
@rw[RA]: 8923          <- 读+预读标志
@rw[WS]: 1520          <- 写+同步标志
*/

这个脚本给真实负载做"I/O 模式画像"，三个维度一次采集。大小分布：4KB 主导说明数据库类随机小 I/O（每个页一个请求），128KB 的批量通常是内核预读（RA 标志证实）或回写合并；如果应用声称"顺序读大文件"但大小分布全是 4KB，说明预读没生效（随机访问模式或预读被禁用）。rwbs 标志字符串是块层的操作类型编码：R=读、W=写、D=discard、F=flush、A=预读（readahead）、S=同步（FUA/强制持久化）、M=元数据——WS（写+同步）高频出现说明应用在频繁做持久化写（O_SYNC 或 fsync 密集），这是写延迟敏感的直接证据。扇区分布的 hist 粗略反映访问的分散度（均匀散布 = 随机，集中 = 顺序热点）。画像的应用：(1) 容量规划——真实模式喂给 fio 复现（fio --bs=4k --rw=randread --iodepth=N），测出设备在该模式下的基线延迟，与生产延迟对比判断"设备退化"还是"负载增长"；(2) 优化验证——开启预读/调整调度器后重新画像，确认 I/O 大小分布的变化（4KB 变 128KB 说明合并生效）；(3) 云配额核对——IOPS 和带宽的乘积关系（4KB×10000 IOPS = 40MB/s，若云盘按两者分别限流，小 I/O 场景先撞 IOPS 墙）。

/* 示例5：fsync 延迟分解——数据库提交路径分析 */
sudo bpftrace -e '
kprobe:vfs_fsync_range { @start[tid] = nsecs; }
kretprobe:vfs_fsync_range /@start[tid]/ {
    @fsync_ms = hist((nsecs - @start[tid]) / 1000000);
    delete(@start[tid]);
}
tracepoint:ext4:ext4_sync_file_enter { @sync_start[tid] = nsecs; }
tracepoint:ext4:ext4_sync_file_exit /@sync_start[tid]/ {
    @ext4_sync_ms = hist((nsecs - @sync_start[tid]) / 1000000);
    delete(@sync_start[tid]);
}'
/* 对比两个直方图：vfs 层 vs ext4 层的 fsync 耗时 */

fsync 是事务型应用（数据库、消息队列、WAL 日志）的性能命门，这个脚本做双层分解：vfs_fsync_range 是 VFS 入口（应用视角的完整 fsync 成本），ext4_sync_file 的 tracepoint 对是文件系统内部（日志提交 + 块层 flush）。两个直方图的差异揭示时间构成：vfs 层 ≈ ext4 层说明成本都在文件系统内（jbd2 日志提交 + 设备 flush）；vfs 层显著大于 ext4 层说明 VFS 到文件系统之间还有开销（如页缓存回写脏页的时间——fsync 要先刷该文件的所有脏页再提交日志）。深入分解的下一层：追踪 jbd2 的提交事件（jbd2_start_commit/jbd2_commit 相关 tracepoint）分离"日志提交"与"数据回写"；biolatency -F 的 Flush 直方图给出设备 flush 命令的延迟。数据库优化的验证场景：开启组提交（MySQL 的 binlog_group_commit_sync_delay、PostgreSQL 的 commit_delay）后，单次 fsync 延迟可能略升但吞吐大增（多个事务共享一次 flush）——用这套分解量化"每事务的持久化成本"（fsync 总时间 / 事务数）才是正确的优化指标。ext4 的 data=ordered 模式（默认）保证数据先于日志落盘，fsync 成本包含数据回写；data=writeback 模式日志先行（fsync 更快但崩溃后可能读到旧数据）——模式选择是持久化延迟与一致性的权衡，BPF 分解数据是决策依据。

/* 示例6：回写行为追踪——脏页与写延迟毛刺 */
sudo bpftrace -e '
kprobe:balance_dirty_pages_ratelimited { @throttled[comm] = count(); }
tracepoint:writeback:writeback_start { @wb_start[args->nr_pages] = count(); }
interval:s:5 { print(@throttled); print(@wb_start); clear(@throttled); clear(@wb_start); }'
/* 同时观察： */
grep -E "Dirty|Writeback" /proc/meminfo
cat /proc/sys/vm/dirty_ratio /proc/sys/vm/dirty_background_ratio

balance_dirty_pages_ratelimited 是写路径的"限流闸口"：进程产生脏页的速度超过回写能力时，内核在这个函数里让进程睡眠（throttle），等待回写跟上——这是"write() 调用偶发几十毫秒延迟"的最常见内核原因（write 本身只是拷入缓存，但拷贝前可能被限流）。脚本统计哪些进程被限流（@throttled）以及回写启动的批量大小分布（writeback_start 的 nr_pages）。配套观察：/proc/meminfo 的 Dirty（当前脏页总量）和 Writeback（正在回写的量）——Dirty 逼近 dirty_ratio 阈值（默认内存的 20%）时限流就会发生。诊断逻辑：写延迟毛刺时刻 + balance_dirty_pages 计数增长 + Dirty 水位高 → 确认是脏页限流 → 解决方案菜单：(1) 调低 dirty_background_ratio（如 5%）让后台回写更早启动，平滑脏页水位；(2) 调低 dirty_ratio 减小单次清算的规模；(3) 应用侧限速（写入平滑化，避免突发洪峰）；(4) 存储侧提速（更快的盘或 RAID 扩容）；(5) cgroup v2 的 memory.high/io 控制器隔离写入大户。大内存机器的特别注意：20% 的 dirty_ratio 在 512GB 内存上是 100GB 脏页——清算一次要按小时计，绝对值阈值（dirty_bytes/dirty_background_bytes）比百分比更适合大内存系统。

实验笔记

本实验构建 I/O 全栈分析能力。预计耗时 3-4 小时。环境：Linux 内核 4.9+，安装 bcc-tools、bpftrace、fio、sysstat。虚拟机可做大部分实验（注意虚拟磁盘的延迟特征与物理设备不同，正好用于理解虚拟化层的影响）。

【实验一：I/O 栈分层测量】(1) 用 fio 构造四种负载并分别测量：4KB 随机读（--rw=randread --bs=4k --direct=1 --iodepth=1）、4KB 随机读高队列（--iodepth=32）、1MB 顺序写（--rw=write --bs=1M）、buffered 4KB 随机读（去掉 --direct）。每种负载下同时运行 biolatency -D 10 1 和 iostat -x 1，记录延迟直方图主峰位置和 iostat 的 await/%util/avgqu-sz。(2) 对比 direct 与 buffered 的延迟差异（buffered 第二次跑应几乎全部命中缓存，biolatency 几乎无事件——验证"缓存命中不进块层"）。(3) 用 ext4dist 10 1 对照文件系统层视角（buffered 场景下 ext4dist 有数据而 biolatency 没有——分层语义差异的实证）。

【实验二：延迟分解定位】(1) 用 cgroup v2 的 io.max 给测试进程限速（如 echo "253:0 wbps=10485760" 限制写带宽 10MB/s），然后跑写负载，用 biosnoop -Q 观察 Q2D 膨胀（内核排队）而 D2C 正常——人为制造"队列拥堵"并验证分解工具能定位它。(2) 用 dm-delay（device mapper 延迟设备，如可用）或虚拟机快照操作制造设备级慢，验证 D2C 膨胀的表现。(3) 写出"Q2D 大 vs D2C 大"的鉴别诊断表。

【实验三：I/O 模式画像】(1) 对实验一的每种 fio 负载运行示例4的画像脚本，记录大小分布和 rwbs 标志，验证画像与 fio 参数的一致性（4KB randread 应显示 @size[4096] 主导 + RA 缺失；顺序读应出现 128KB 的 RA 预读 I/O）。(2) 对一个真实应用（如编译内核 make -j、或数据库 sysbench）做画像，与 fio 模式对比。(3) 调整 read_ahead_kb（echo 0 和 echo 1024）重跑顺序读负载，观察画像中预读 I/O 大小的变化和总吞吐差异——量化预读的价值。

【实验四：fsync 与回写分析】(1) 写一个程序：循环 write 4KB + fsync，测量每次 fsync 耗时（示例5的双层脚本）；(2) 对比 O_SYNC 打开文件直接 write 与 write+fsync 的延迟差异；(3) 制造脏页压力：大内存机器上高速写入（dd bs=1M 写到文件），观察 /proc/meminfo 的 Dirty 增长曲线、balance_dirty_pages 限流计数、以及并发的小写入进程的延迟毛刺（用示例6脚本 + fileslower 10 抓毛刺）；(4) 调整 dirty_background_ratio 从 10 到 2，重复实验观察毛刺变化。

【实验五：完整排查演练】模拟一个"数据库写延迟毛刺"场景：启动 sysbench oltp_write_only（或自写 SQL 循环），同时用 cgroup 限制磁盘带宽制造资源紧张，用 dd 制造缓存冲刷干扰。只允许使用本章工具（biolatency、biosnoop、ext4slower、fileslower、示例5/6 脚本），写出完整排查报告：现象 → 分层测量 → 延迟分解 → 模式画像 → 根因（限流/设备慢/回写压力/缓存冲刷中的哪些）→ 解决方案建议。

【实验报告要求】全部实验的数据表格（每种负载的延迟主峰、Q2D/D2C 分解、模式画像）、实验二的鉴别诊断表、实验五的排查报告。附加思考：(1) NVMe 设备上 iostat 的 %util=100% 为什么不代表饱和？（提示：多队列并行，%util 只表示"至少一个队列忙"的时间占比。）(2) 为什么 HDD 上 I/O 合并（调度器功能）对性能至关重要而 NVMe 上收益甚微？

延伸阅读

• Brendan Gregg, "BPF Performance Tools" 第 8 章——本章原始出处，含磁盘与文件系统工具全表、I/O 栈图解和 blk-mq 架构说明。
• 《深入理解计算机系统》(CSAPP) 第 6 章 (存储器层次结构) 与第 10 章 (系统级 I/O)——I/O 的硬件基础（磁盘几何、SSD 原理）和 Unix I/O 接口的教科书讲解，理解"为什么随机比顺序慢"的物理根源。
• Linux 块层文档 Documentation/block/ 目录——blk-mq.rst（多队列架构）、queue-sysfs.rst（/sys/block 全部调优参数）、switching-sched.rst（调度器选择），块层调优的权威参考。
• fio 文档 (fio.readthedocs.io)——负载生成器的完整参数手册，ioengine 选择（libaio/io_uring/sync）、延迟百分位输出（clat percentiles）是存储基准测试的必备知识。
• Brendan Gregg, "Systems Performance" 第 2 版第 9 章 (Disks) 与第 10 章 (File Systems)——存储子系统的百科讲解，含 RAID、SSD 内部机制（FTL、GC、磨损均衡）的性能影响分析。
• ext4/xfs 内核文档 (Documentation/filesystems/ext4.rst 等) 与 jbd2 设计文档——文件系统日志机制的实现细节，理解 fsync 成本构成（数据回写 + 日志提交 + flush）的底层依据。
• io_uring 系列文章 (lwn.net, "Efficient IO with io_uring")——新一代异步 I/O 接口，正在取代 libaio 成为高性能存储应用的标准，其 BPF 追踪点（io_uring tracepoints）是未来的分析对象。
• 各云厂商的 EBS/云盘性能文档（如 AWS EBS volume types）——burst 机制、IOPS/吞吐配额、延迟 SLO 的官方说明，云环境存储分析的基线参考。