Linux无法直接查询控制器“支持的最高IOPS”，因该值是负载、队列深度、IO大小等动态因素决定的理论估算值，需结合lspci查PCIe带宽、nvme id-ctrl查协议版本与MDTS、nvme id-ns查命名空间参数综合推算，iostat显示的是实际下发IOPS而非硬件上限。
Linux无法直接查控制器“支持的最高IOPS”
控制器本身不对外暴露“理论最大 IOPS”这个数值，Linux 内核和用户态工具（如 iostat、lshw、lspci）只反映当前运行时的实际行为或硬件规格描述，不会告诉你“这颗 NVMe 控制器最多能跑多少 IOPS”。所谓“最高 IOPS”是负载、队列深度、IO 大小、协议开销、固件策略共同决定的动态结果，不是写死在寄存器里的参数。
看 PCIe 通道数和 NVMe 协议版本能估算理论上限
真正可查、且对 IOPS 有硬性约束的是物理层能力。你需要组合查以下三项：
-
lspci -vv -s $(lspci | grep -i nvme | head -n1 | awk '{print $1}') | grep -E "(LnkCap|LnkSta)"—— 看LnkCap中的Speed（如 8.0 GT/s）和Width（如x4），这是 PCIe 带宽天花板 -
sudo nvme id-ctrl /dev/nvme0n1 | grep -i "ver\|mdts"—— 查ver字段确认 NVMe 协议版本（1.2/1.3/1.4/2.0），版本越高，命令处理效率和队列管理越强；mdts是最大数据传输大小（单位为 2^mdts× 512B），影响单次 IO 上限 -
sudo nvme id-ns /dev/nvme0n1 | grep -i "npwg\|npwa\|nacwu"—— 这些是命名空间级的写入粒度与对齐要求，间接限制小 IO 效率
例如：PCIe 4.0 x4 + NVMe 1.4 + 支持 64K 最大队列深度的盘，4K 随机读理论峰值常被厂商标为 700K~1M IOPS —— 但这只是参考值，实际受驱动、内核 IO 调度、libaio 配置等层层压制。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
iostat -x 显示的是真实下发值，不是控制器上限
很多人误把 iostat -x 的 r_ios/w_ios 当成“控制器能力”，其实它只是告诉你“过去一秒里，设备驱动向控制器发了多少个请求”。它可能远低于上限（比如业务没压满），也可能因队列拥塞而卡在低位（await > 20ms 且 avgqu-sz 持续 > 32）。关键区别在于：
-
r_ios是观测结果，不是规格参数 - 如果
%util长期 r_ios 已到 300K，说明瓶颈不在控制器，而在上层（如文件系统锁、page cache 回写策略、应用线程数不足） - 若
avgqu-sz接近nvme id-ctrl报出的nn（Number of Namespaces）×mqes（Maximum Queue Entries Supported），才说明控制器队列真被填满了
真要测出控制器逼近极限的 IOPS，只能靠 fio 施压
没有“查看”命令，只有“打出来”。用 fio 逼近控制器能力需满足三个条件：
- 绕过所有缓存：
direct=1+invalidate=1 - 榨干队列深度：
iodepth=256或更高（需先查nvme id-ctrl的mqes值） - 用足够并发任务模拟真实压力：
numjobs=16或32，避免单线程成为瓶颈
典型命令：fio --name=test --ioengine=libaio --rw=randread --bs=4k --iodepth=256 --numjobs=32 --direct=1 --invalidate=1 --runtime=30 --time_based --filename=/dev/nvme0n1 --group_reporting
注意：此操作会极大占用设备，务必在维护窗口执行，且不能在生产数据盘上直接跑裸设备测试。
最易被忽略的一点：NVMe 控制器的“最高 IOPS”永远依赖于具体 workload —— 同一块盘，4K 随机读能到 800K，4K 随机写可能只有 200K，而 128K 顺序读又会掉到 100K。别信单一数字，要看你的真实 IO 模式。
