ioprio_set 对备份进程无效，主因是现代内核（5.0+）已移除cfq调度器，ionice -c 3（idle类）退化为best-effort甚至被忽略；应改用ionice -c 2 -n 7或cgroups v2的io.max硬限速。
为什么 ioprio_set 对备份进程没生效？
直接用 ionice -c 3 -p $PID 后发现磁盘 IO 还是抢资源，大概率是因为进程没真正运行在 idle 类（class 3），或者内核不支持 CFQ 调度器（较新内核默认用 mq-deadline 或 kyber）。ionice 的 class 3（idle）仅在无其他进程竞争时才获得 IO 时间片，且只对 CFQ 生效；5.0+ 内核中 CFQ 已被移除，ionice -c 3 实际退化为 best-effort（class 2）甚至被忽略。
实操建议：
- 先确认当前 IO 调度器：
cat /sys/block/*/queue/scheduler，若输出含[mq-deadline]或[kyber]，说明ionice -c 3基本无效 - 检查进程实际 ioprio 值：
ionice -p $PID，若显示best-effort: prio 4却期望是idle，说明内核已静默降级 - 不要依赖
-c 3在现代发行版上“彻底让出 IO”，它更像一个弱提示而非强制策略
用 ionice -c 2 配合 -n 显式压低优先级
在非 CFQ 环境下，ionice -c 2（best-effort）是唯一可靠选项，配合 -n 7（最高 nice 值）可显著降低 IO 抢占能力。注意：这里的 -n 不是 CPU nice，而是 IO 优先级中的“优先级值”，范围 0–7，数值越大越低。
实操建议：
- 启动备份前设置：
ionice -c 2 -n 7 rsync -a /data/ /backup/ - 对已运行进程补设：
ionice -c 2 -n 7 -p $(pgrep -f "rsync.*backup") - 验证是否生效：
ionice -p $PID应返回best-effort: prio 7 - 避免混用
-c 1（realtime）——它会加剧干扰，且普通用户通常无权限
配合 cgroups v2 做硬性 IO 限速（推荐长期方案）
当 ionice 表现不稳定或需强约束时，cgroups v2 的 io.max 是更可控的选择。它不依赖调度器类型，直接限制每秒 IO 字节数和 IOPS，适合备份这类可预测吞吐的场景。
实操建议：
- 创建 cgroup：
sudo mkdir -p /sys/fs/cgroup/backup-io - 设限（例如限 10MB/s 顺序读写）：
echo '8:0 rbps=10485760 wbps=10485760' | sudo tee /sys/fs/cgroup/backup-io/io.max（8:0是lsblk查得的主磁盘主次设备号） - 将进程加入组：
echo $PID | sudo tee /sys/fs/cgroup/backup-io/cgroup.procs - 注意：必须确保系统启用 cgroups v2（
mount | grep cgroup显示cgroup2），且内核 ≥ 5.0
备份脚本里怎么安全集成 IO 控制？
直接在 crontab 里调 ionice 容易因环境变量或 shell 差异失效；用 cgroup 则需避免 PID 竞态。关键点是“进程启动即受控”，不是事后打补丁。
实操建议：
- 用
systemd --scope启动（最稳妥）：systemd-run --scope -p IOWeight=10 --unit=backup-rsync rsync -a /data/ /backup/（IOWeight仅在 systemd 245+ 且使用bfq或mq-deadline时部分生效，但比裸ionice更一致） - 若坚持脚本方式，用
exec ionice -c 2 -n 7 "$@"替换原始命令开头，确保子进程继承 ioprio - 永远在备份命令前后加
ionice -p $$日志，确认当前 shell 进程的 ioprio 是否被正确继承
真正难的是权衡：ionice 简单但不可靠，cgroup 精确但需 root 和额外维护。生产环境备份若跑在虚拟机或容器里，IO 权重往往已被上层调度器截断，这时候看宿主机配置比调本地参数更有效。
