直接运行 ionice -p pid 即可查看进程当前io优先级，输出如“io class: idle”或“io class: best-effort, io priority: 4”，默认未设置时通常显示best-effort优先级4；-c 3（idle）不可跟-n参数，普通用户无法查看realtime类进程。
怎么用 ionice 查看进程当前 IO 优先级
直接运行 ionice -p PID 就能看到，不需要额外工具或权限（只要能读取该进程状态）。
例如查 PID 1234 的 IO 设置：ionice -p 1234
输出类似 io class: idle 或 io class: best-effort, io priority: 4，含义一目了然。
- 如果进程没显式设置过，通常显示
best-effort, io priority: 4（默认值） - 对 Realtime 类进程，普通用户执行会报
Permission denied，即使有权限也建议避免查这类进程——它们本就不该被随意观测 -
ionice -p不支持通配或模糊匹配，必须指定确切 PID；批量查可用pgrep name | xargs -r ionice -p
ionice -c 和 -n 参数到底怎么配才合法
不是所有 -c 和 -n 组合都有效：Class 决定是否允许带 -n，以及允许的取值范围。
-
-c 0（None）：已弃用，等效于-c 2，不推荐用；-n被忽略 -
-c 1（Realtime）：仅 root 可用；-n必须是 0–7，但设成 0 实际等于“抢光所有磁盘时间”，极易卡死 SSH 或 journal -
-c 2（Best-effort）：普通用户主力选项；-n0–7 合法，0 最高（慎用），6–7 更安全 -
-c 3（Idle）：普通用户可用；-n**完全不允许**，加了会报错invalid argument
错误示例：ionice -c3 -n5 find / -name "*.log" → 直接失败。正确写法是 ionice -c3 find / -name "*.log"。
为什么 ionice 在 SSD 上好像没效果
不是命令坏了，是底层机制变了：ionice 控制的是请求入队顺序和调度频次，而 SSD 几乎没有寻道延迟，CFQ/BFQ 调度器的“排队优化”收益大幅降低。
- 在 HDD 上，
ionice -c3能明显推迟后台 rsync 对前台数据库查询的影响；在 NVMe 上，这种延迟差可能压到毫秒级，肉眼/监控难感知 - 但仍有作用：哪怕 SSD，多个进程并发刷写时仍会争抢队列深度和控制器资源，
ionice -c3仍可减少其抢占行为 - 验证是否生效？别只看响应时间，用
iotop -o观察实际 I/O 带宽占比，Idle 类进程在有负载时应长期显示0.00%
ionice 和 nice 真的能一起用吗
能，而且非常有必要——CPU 和 I/O 是两套独立调度系统，只调一个等于只绑一只手。
- 典型组合：
nice -n19 ionice -c3 tar -cf backup.tar /bigdir，既让出 CPU 时间片，又让出磁盘时间片 - 注意顺序：
nice必须放在ionice前面，否则ionice启动的子进程不会继承 nice 值 - 不要迷信 “-n19 + -c3 = 完全无感”：若目标路径在 busybox 挂载的 tmpfs 或 overlayfs 上，I/O 会转为内存操作，ionice 失效，此时只靠 nice 生效
真正容易被忽略的点：ionice 设置的是请求调度权，不是带宽上限。想限速（比如不让 rsync 超过 10MB/s），得用 cgroups v2 配置 io.max，ionice 做不到。
