iostat -x 无法直接显示元数据读写占比，因其 rMB/s 和 wMB/s 统计所有块设备 I/O，内核 block layer 未暴露“元数据 vs 用户数据”维度；元数据操作需结合 iotop、/proc/PID/io、lsof 及 bpftrace（hook 文件系统层）综合定位，且实际中元数据常与用户数据混合在同一请求中，占比本身无内核级定义。
为什么 iostat -x 无法直接看到元数据读写占比
iostat -x 输出的 rMB/s 和 wMB/s 是全部块设备读写吞吐，不区分用户数据与元数据（如 ext4 的 inode、xattr、journal、btrfs 的 tree node、log 等）。内核没有在通用 block layer 暴露“元数据 vs 数据”的统计维度，所有 I/O 都被统一计为 read_bytes/write_bytes。所以你查不到现成字段。
用 /proc/PID/io + lsof 定位疑似元数据密集型进程
元数据操作通常由文件系统层或数据库 WAL 日志驱动，集中在少数进程：比如 mysqld（InnoDB redo log）、postgres（WAL 写入）、journald（journal 文件刷盘）、rsync（大量 stat/chmod）、find（遍历目录树）。
- 先用
iotop -o -d 1找出 WRITE 高的进程 PID - 对每个 PID 执行：
cat /proc/<pid>/io</pid>，重点看read_bytes和write_bytes—— 如果数值远小于rchar/wchar，说明大量操作卡在 page cache 或元数据路径（如stat()不触发块读，但readdir()可能读目录块） - 再执行：
lsof -p <pid> | grep -E '\.(log|journal|jnl|tree|db)$'</pid>，匹配典型元数据文件后缀；若看到/var/log/journal/、/var/lib/mysql/ib_logfile0、/var/lib/postgresql/*/main/pg_wal/，基本可判定是元数据写密集型负载
用 bpftrace 抓 ext4/btrfs 元数据 I/O（需 5.0+ 内核）
这是目前唯一能近似分离元数据 I/O 的方法，原理是 hook 文件系统层 write path，过滤 flag 含 REQ_META 或路径含 journal/log 目录的 request。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
示例脚本（仅 root 可运行）：
bpftrace -e '
kprobe:ext4_writepages /pid == 1234/ {
@meta_bytes = sum(args->wbc->nr_to_write * 4096);
}
'注意：
- ext4_writepages 和 btrfs_submit_bio_hook 等 tracepoint 因内核版本和 fs 类型差异很大，不能通用
- REQ_META 标志只在部分路径（如 journal 提交）被设置，普通 mkdir 或 chmod 可能不带该 flag
- 实际占比需人工比对：把抓到的元数据字节数 ÷ iostat -x 1 的 wMB/s × 1024 × 采样秒数
真正容易被忽略的地方
元数据读写不是独立流量，它常和用户数据混在同一个 I/O 请求里——比如一次 4KB 写可能包含 1 个 inode 更新 + 3KB 文件内容；一次 64KB 顺序写背后可能是 8 个分散的 metadata block 被合并提交。所以“占比”本身是个模糊概念，没有内核级定义。与其纠结精确数字，不如盯住 iostat -x 的 rrqm/s（读请求合并率）和 wrqm/s（写请求合并率）：如果两者都持续 >50，大概率是小 IO 密集场景，其中元数据占比较高。
