必须加 -p all 才能看到分区级吞吐，因默认 iostat -x 仅显示主设备（如 sda），-p 启用每分区统计，all 包含 lvm、raid、nvme 等所有子设备；-p 与 -x 必须共存才输出 rmb/s/wmb/s 字段。
直接用 iostat -xh 1 -p ALL，这是唯一能同时看清每个分区（含 LVM、md、nvme-part）实时吞吐走势的方式；其他命令要么不拆分到分区级，要么数据来源不可靠。
为什么必须加 -p ALL 才能看到分区级吞吐
默认 iostat -x 只显示主设备（如 sda、nvme0n1），不展示其下的分区（sda1、nvme0n1p1）或逻辑卷。而 -p 参数才启用“per-partition”统计，ALL 表示包含所有块设备及其子设备——LVM 的 dm-0、RAID 的 md0、NVMe 的 nvmep1 全部在列。
-
-p和-x必须共存：iostat -x -p是有效组合；单独-p不输出rMB/s/wMB/s字段 - 不加
ALL时，-p默认只显示主设备 + 直接子分区，漏掉 LVM/RAID 等中间层设备 -
/proc/diskstats虽然也含分区数据，但单位是扇区（512B）、无缓存过滤、需手动换算，不适合实时走势观察
iostat -xh 1 -p ALL 输出里哪些字段代表真实分区吞吐
盯紧 rMB/s 和 wMB/s 两列——它们是绕过 page cache、从块设备驱动直接上报的读写速率，单位自动缩放（K/M/G），数值可直接对标 SSD 厂商标称带宽。别看 rkB/s/wkB/s 或 r/s/w/s，前者受缓存干扰严重，后者被请求合并扭曲，都不能反映分区真实吞吐走势。
-
rMB/s和wMB/s是唯一可信的吞吐指标，且按设备名对齐，一眼看出sda1和sda2各自的实时负载 - 若某分区
rMB/s长期为 0，但主设备sda有值，说明读集中在其他分区或未命中该分区（比如 swap 在sda2） - 注意字段名仍是
rMB/s，哪怕你用-xk：这是历史兼容设计，数值已按 KB 换算，但列名不变
常见误判场景和替代方案的坑
想画图或导出走势？别用 dstat -D sda1 或 vmstat，它们不支持分区粒度，且 dstat 的 disk read 列来自 VFS 层，缓存命中时会虚高数倍；vmstat 的 bi/bo 是全系统汇总、单位是 512B 块、无法区分设备。
-
iotop -o -d 1可定位进程，但它的DISK READ/WRITE是/proc/[pid]/io的rchar/wchar，含缓存，和iostat分区吞吐不匹配 - 脚本采集时，避免用
awk '/sda1/ {print $3,$4}'直接切默认输出——首行是平均值（冷启动噪音），应跳过或用iostat -xh 1 -p ALL 3 2控制总次数 - 如果
-p ALL输出里看不到预期分区（如dm-2），检查是否被 udev 规则隐藏，或运行lsblk确认设备路径是否一致
真正容易被忽略的是：分区吞吐不是简单叠加，sda1 + sda2 的 rMB/s 之和通常小于 sda 的 rMB/s —— 因为部分 IO（如元数据、superblock 访问）落在设备层但不归属任何分区；要验证物理介质真实完成量，得查 /sys/block/sda/stat 第 1/5 列，但那是累计值，不能直接当实时走势用。
