Linux 系统中怎么使用 systemtap 跟踪底层磁盘 I/O 调用栈-linux运维-PHP中文网

systemtap通过捕获block层tracepoint（如ioblock.request/end）并结合kernel_backtrace()回溯调用栈，精准定位磁盘i/o延迟卡点，支持按设备、进程、读写方向等条件过滤分析。

linux 系统中怎么使用 systemtap 跟踪底层磁盘 i/o 调用栈

用 SystemTap 跟踪底层磁盘 I/O 调用栈，核心是捕获块层（block layer）关键事件，并沿调用路径向上回溯内核函数栈。它不是看“谁在读写文件”，而是看“数据从进程发出后，经过哪些内核函数最终抵达设备驱动”。这能精准定位延迟卡点——比如卡在调度器排队、卡在 bio 合并、还是卡在 request_queue 提交环节。

确认可用的 block 层探针

SystemTap 依赖内核 tracepoint 支持。先列出当前系统支持的磁盘 I/O 相关探针：

stap -L 'ioblock.*' —— 显示块设备 I/O 事件，如 ioblock.request（请求生成）、ioblock.end（请求完成）
stap -L 'ioscheduler.*' —— 查看调度器行为，如 ioscheduler.elv_issue_request（下发请求）、ioscheduler.elv_completed_request（完成回调）
stap -L 'block.*' —— 更底层的块层 tracepoint（需内核开启 CONFIG_BLOCK_TORTURE_TEST 或对应 trace 选项），例如 block:block_rq_issue、block:block_rq_complete

若无输出，说明缺少 debuginfo 包或内核未启用 tracepoint。需确保已安装对应版本的 kernel-debuginfo 和 kernel-devel，并挂载 debugfs：mount -t debugfs none /sys/kernel/debug。

捕获请求发起时的完整内核调用栈

以下脚本在每个新 I/O 请求生成时，打印其调用栈（含进程名、PID、函数名序列）：

probe ioblock.request {
    printf("[%s][%d] %s → %s (dev=%s, sector=%d, rw=%d)\n",
        execname(), pid(), probefunc(),
        kernel_backtrace(),
        devname, sector, rw)
}

说明：

Linux installer

先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。

下载

execname() 和 pid() 标识触发 I/O 的用户进程
probefunc() 返回当前探针所在函数（通常是 generic_make_request 或 submit_bio）
kernel_backtrace() 输出从该点往上的内核函数调用链，长度默认 16 层，可加参数控制
sector、rw 等字段来自探针自动注入的上下文变量（见 stap -L ioblock.request 输出）

关联请求生命周期，识别延迟瓶颈

单看入口不够，要对比“发出”和“完成”的时间差。下面脚本为每个 bio 请求打标计时，并在完成时输出耗时及栈：

global io_start
probe ioblock.request {
    io_start[pid(), $bio] = gettimeofday_us()
}
probe ioblock.end {
    start = io_start[pid(), $bio]
    if (start) {
        delta = gettimeofday_us() - start
        if (delta > 10000) {  // 只打印 >10ms 的慢请求
            printf("[%s][%d] slow IO: %d us → %s\n",
                execname(), pid(), delta, kernel_backtrace())
        }
        delete io_start[pid(), $bio]
    }
}

这个逻辑能帮你发现：是 make_request 内部卡住（比如 ext4 日志锁竞争），还是在 elv_add_request 排队太久（调度器饥饿），或是 scsi_dispatch_cmd 阶段阻塞（驱动或硬件问题）。