blktrace 是 linux 内核原生块层 i/o 跟踪工具，用于分析调度器排队（i2d）和硬件响应（d2c）等底层性能瓶颈，而非文件系统层问题；需配合 blkparse 和 btt 使用，并依赖 debugfs 挂载与 root 权限。

Linux 文件系统性能分析中，btrace 并非标准工具，实际并不存在独立的 btrace 命令——这是常见误解。你很可能指的是 blktrace（常被误拼或口误为 btrace），它是 Linux 内核原生支持的、专用于块层（block layer）I/O 跟踪的核心工具。它不跟踪文件系统层（如 ext4/xfs 的 inode 操作或 page cache 行为），而是深入到通用块层，记录 I/O 请求从生成到完成的全生命周期事件。

要准确分析文件系统性能瓶颈，需明确：文件系统层（VFS → fs → page cache）和块层（block → driver → device）是两个不同层级。blktrace 解决的是后者——即“请求是否被合理调度？硬件响应是否延迟？”，而非“为什么 write() 调用慢？是日志刷盘阻塞还是元数据锁争用？”这类文件系统内部问题。

以下围绕 blktrace 及其配套工具链，给出实用、可落地的 IO 性能分析路径：

blktrace 采集前必须确认的基础条件

• /sys/kernel/debug 必须已挂载 debugfs：

  mount -t debugfs none /sys/kernel/debug 2>/dev/null || true

• 目标块设备（如 /dev/sda）需处于活跃状态，且无其他 trace 正在运行（避免干扰）。
• 需 root 权限；普通用户无法访问 trace 数据。
• 确保内核启用 CONFIG_BLK_DEV_IO_TRACE=y（主流发行版默认开启）。

使用 blktrace + blkparse 定位 I/O 卡点位置

blktrace 本身只采集原始二进制事件流，必须配合 blkparse 才能解读。典型流程：

# 采集 30 秒 sda 的 I/O 事件（按 CPU 分片，生成 sda.blktrace.0, sda.blktrace.1...）
blktrace -d /dev/sda -w 30 -o sda.trace

# 合并所有 CPU trace 文件，并解析为人类可读格式
blkparse -i sda.trace -o sda.parsed

# 查看关键阶段耗时（重点关注 Q2G、G2I、I2D、D2C）
grep -E "Q|G|I|D|C" sda.parsed | head -20

输出示例：

8,0   0    1     0.000123456  12345  Q R 12345678 + 8 [dd]
8,0   0    2     0.000123789  12345  G R 12345678 + 8 [dd]
8,0   0    3     0.000124123  12345  I R 12345678 + 8 [dd]
8,0   0    4     0.000125678  12345  D R 12345678 + 8 [dd]
8,0   0    5     0.000130123  12345  C R 12345678 + 8 [dd]

从中可计算：

onewo-rtlinux

Linux 实时编程助手。生成、审查并修改用于周期性控制任务和中断驱动程序的 C 代码。强制实施实时调度策略。

下载

• Q2G ≈ 0.000000333s（remap/split 开销，通常极小）
• G2I ≈ 0.000000334s（merge 开销）
• I2D ≈ 0.000001555s（调度器排队时间，若 > 1ms 需检查 scheduler 类型与队列深度）
• D2C ≈ 0.000004445s（驱动+硬件耗时，若显著高于磁盘标称延迟，说明硬件或 HBA 异常）

结合 btt 获取吞吐量、IOPS 和延迟分布

btt（blktrace time tool）对 blkparse 输出进一步聚合统计：

btt -i sda.trace -o sda_btt

生成的 sda_btt.sys_iops_fp.dat 和 sda_btt.sys_mbps_fs.dat 可直接绘图；sda_btt.avgrq-sz.dat 显示平均请求大小；sda_btt.await.dat 给出真实 await（等效于 iostat 的 await，但来源更底层）。

关键判断逻辑：

• 若 D2C 高而 I2D 低 → 问题在硬件链路（磁盘故障、RAID 卡缓存关闭、HBA 驱动异常）
• 若 I2D 高而 D2C 正常 → 调度器瓶颈（如 CFQ 在高并发下表现差，可尝试 deadline 或 none）
• 若 Q2G 或 G2I 异常高 → 可能存在大量 unaligned I/O 或极端小 IO 导致频繁 split/merge（常见于数据库日志写或碎片化文件读）

补充建议：文件系统层问题请换用其他工具

若怀疑是 ext4 journal 刷盘慢、XFS allocation group 锁争用、或 page cache 回写压力大：

• 用 perf record -e block:block_rq_issue,block:block_rq_complete 抓取块层事件 + 关联进程栈
• 用 xfs_info / tune2fs -l 检查文件系统参数（如 inode64、lazy_itable_init）
• 用 cat /proc/fs/xfs/stat（XFS）或 dmesg | grep -i "ext4" 观察错误/警告
• 用 biosnoop（bpftrace 工具）快速查看每个 I/O 的 PID + 延迟，定位肇事进程

不依赖 blktrace 也能发现很多问题，但它仍是唯一能穿透调度器、直击硬件响应时间的权威手段。