iostat 不支持 -d 选项，无法直接显示扇区大小下的读写放大；需通过 lsblk/blockdev 确认逻辑与物理扇区大小，结合 iostat -x 观察 avgrq-sz、r/s 异常及 dd/fio 非对齐测试验证 rmw 放大。
1. 先确认真实扇区大小（Logical vs Physical）
这是分析放大的前提。使用 `lsblk` 或 `blockdev`：
-
lsblk -o NAME,LOG-SEC,PHY-SEC,ROTA,MODEL /dev/sdX→ 显示逻辑扇区（LOG-SEC）和物理扇区（PHY-SEC） -
sudo blockdev --getss /dev/sdX→ 当前逻辑扇区大小（通常 512 或 4096） -
sudo blockdev --getpbsz /dev/sdX→ 物理扇区大小（如 4096，常见于 Advanced Format 硬盘或 SSD）
若 LOG-SEC=512、PHY-SEC=4096，且上层（文件系统、应用）发出未对齐的 512B 写入，则极可能触发读-改-写放大（1 次写请求 → 实际 1 次读 + 1 次写 = 2×物理 I/O）。
2. 用 iostat 观察“现象级”放大线索
虽然 `iostat` 不直接标出放大倍数，但可通过关键指标间接识别：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 运行
iostat -x 1（启用扩展统计，每秒刷新） - 重点关注：
• r/s 和 w/s（每秒 I/O 请求次数）
• rkB/s 和 wkB/s（每秒读写千字节数）
• avgrq-sz（平均请求大小，单位为扇区；即(wkB/s × 2) / w/s）
• avgqu-sz（平均队列深度）、%util（设备忙时百分比）
放大典型表现：
– 应用只写 4KB（8 个 512B 扇区），但 avgrq-sz 显示为 16（即 8KB 请求）或更高；
– w/s 较低，但 avgrq-sz 异常大，同时 r/s 显著升高（暗示后台读操作）；
– %util 高而吞吐（wkB/s）偏低 → 效率下降，是放大的常见副作用。
3. 主动构造非对齐 I/O 并对比验证
用 `dd` + `od` 或 `fio` 发送可控偏移的写入，观察 `iostat` 变化：
- 对齐写（安全基准）：
dd if=/dev/zero of=/mnt/testfile bs=4k count=1000 oflag=direct - 非对齐写（触发放大）：
dd if=/dev/zero of=/mnt/testfile bs=512 seek=1 count=8 oflag=direct（写 8×512B，起始偏移 512B → 跨越两个 4K 物理页） - 运行
iostat -x 1同时执行上述命令，对比两组的r/s、w/s、avgrq-sz—— 非对齐场景下r/s往往明显上升，avgrq-sz可能翻倍。
4. 结合其他工具交叉印证
`iostat` 是窗口，不是显微镜。需搭配：
-
cat /proc/diskstats：查看底层计数器，其中第 3 列（reads completed）和第 7 列（writes completed）可反映实际完成的读写次数，比 iostat 更底层； -
perf record -e block:block_rq_issue,block:block_rq_complete -a sleep 10：抓取块层请求生命周期，可看到单个 write request 是否伴随 read request； -
smartctl -a /dev/sdX | grep -i "sector\|rotation"：确认设备是否为 4Kn/512e 模式，这对解释放大根源至关重要。
