无法直接查询磁盘控制器iops上限，需结合物理型号查厂商文档，并用fio实测验证；nvme单队列上限≈队列深度×1000 iops（4k随机读），多队列可线性叠加，而iostat的r/s仅反映当前负载非能力边界。
Linux 里没有命令能直接查磁盘控制器 IOPS 上限
控制器本身不对外暴露“最大 IOPS”这个数值，iostat、smartctl、lshw 都不提供该字段。所谓“上限”，是硬件规格、协议栈、队列深度、驱动和负载模式共同决定的理论值，不是运行时可读取的寄存器值。
怎么估算 NVMe/SCSI 控制器的 IOPS 潜力
必须分层看：先确认物理控制器型号，再查厂商文档，最后用 fio 实测验证。别指望靠 iostat -x 的 r_ios/w_ios 反推上限——它只反映当前负载，不是能力边界。
- NVMe 控制器：查
lspci -vv -s $(lspci | grep -i nvme | awk '{print $1}') | grep "Queue Depth"，典型值是 64/128/256；单队列上限 ≈ 队列深度 × 1000 IOPS（4K 随机读），多队列可线性叠加 - SCSI/SATA 控制器：看
cat /sys/block/sdX/device/queue_depth，HBA 卡通常为 32~256；实际并发能力受nr_requests和调度器限制 - 注意
cat /sys/block/nvme0n1/queue/nr_requests和/sys/block/nvme0n1/queue/io_poll_delay会影响小 IO 吞吐密度
为什么 iostat -x 的 r_ios 不能当上限用
r_ios 是驱动上报的实际下发次数，它受上层合并（rrqm/s）、IO 调度器节流、CPU 调度延迟、文件系统日志开销等影响。你看到 50K IOPS，不等于控制器能跑满 50K —— 很可能只是 fio 压测时触发了队列饱和，%util 到 100%、await 暴涨、avgqu-sz 突增才是逼近极限的信号。
- SSD 上
%util才 60% 就await > 10ms→ 队列深度或控制器固件已瓶颈，不是 NAND 速度问题 - HDD 上
r_ios > 200且await > 30ms→ 机械寻道已达物理极限，再压没意义 -
avgrq-sz长期
实测时绕过干扰才能逼近控制器真实能力
用 fio 直通设备、禁用缓存、固定队列深度，才能逼近控制器吞吐天花板。dd 不行，它单线程、无队列、无法模拟并发请求压力。
- 最小可行命令：
fio -name=test -ioengine=libaio -direct=1 -rw=randread -bs=4k -iodepth=128 -numjobs=4 -runtime=60 -filename=/dev/nvme0n1 -group_reporting - 关键参数：
-iodepth必须 ≥ 控制器标称队列深度；-numjobs多进程打满 CPU 核心，避免单核瓶颈 - 对比
iostat -x 1输出：r_ios应接近iodepth × numjobs，若远低于，说明控制器/驱动/PCIe 通道已卡住 - PCIe 插槽带宽也要查：
lspci -vv -s $(lspci | grep -i nvme | head -1 | awk '{print $1}') | grep "LnkCap\|LnkSta"，x4 通道理论上限约 4GB/s，IOPS 受块大小制约
