必须指定设备名，用sudo cat /sys/block/设备名/queue/scheduler查看，方括号内为当前激活项；nvme和云盘显示[none]属正常，不可写也不需改。
怎么查某块盘当前用的 IO 调度器
Linux 没有“系统级”调度策略，每个块设备（如 sda、nvme0n1）独立配置，必须指定设备名才能查准。直接看 /sys/block/设备名/queue/scheduler：
- 先确认设备名：
lsblk -d或cat /proc/partitions，排除loop、dm-、zram等非物理设备 - 查
sda的调度器：cat /sys/block/sda/queue/scheduler，输出形如noop [mq-deadline] kyber，方括号里的是当前激活项 -
nvme0n1常见输出是[none]——这不是错误，是内核绕过软件调度层，此时该路径不可写，也不需改 - 若看到
[cfq]且设备是 SATA SSD，才值得考虑切换；HDD 通常默认mq-deadline，无需干预
为什么 cat /sys/block/xxx/queue/scheduler 返回 Permission denied
这个路径只允许 root 读取，普通用户执行会失败。不是权限配置问题，是内核强制限制：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 必须加
sudo：例如sudo cat /sys/block/sda/queue/scheduler - 不要尝试用
chmod或修改 sysctl —— 该接口由内核只读暴露，硬改会导致 panic 或静默失败 - 某些容器环境（如 Docker 默认 cgroup v2）中，即使 root 也可能被 namespace 隔离，看不到宿主机设备路径，此时应进宿主机查
echo 写入 scheduler 失败的常见原因
运行时切换调度器看似简单，但失败很常见，多数是因为没看清当前支持的选项或设备类型不匹配：
- 只能写入
cat输出中列出的名称（比如输出是noop [mq-deadline]，就不能写cfq） - 对 NVMe 设备强行写
noop或deadline，结果仍是[none]，因为驱动不接受 - 部分 RAID 卡或旧内核（mq-deadline，写入后
cat仍显示原值，说明内核拒绝了请求 - 命令必须带
sh -c：正确写法是sudo sh -c 'echo mq-deadline > /sys/block/sda/queue/scheduler'，直接sudo echo xxx > ...会因重定向权限失败
云服务器上查不到 scheduler 怎么办
阿里云云盘、AWS EBS、腾讯云 CBS 等主流云盘普遍屏蔽了该接口，这是有意设计，不是你漏步骤：
- 执行
cat /sys/block/vda/queue/scheduler可能只返回[none]或报错No such file or directory - 云厂商在存储网关层已做调度优化，暴露内核调度器反而干扰其 I/O 路径，所以直接禁用
- 此时别折腾
elevator=参数——GRUB 加了也无效，启动日志里会出现elevator: ignoring, not supported类似提示 - 判断云盘性能应依赖
iostat -xk 1和dd iflag=direct实测，而非调度器类型
[none] 在 NVMe 和云盘上是正常态，不是故障，也不是可调项**。强行覆盖不仅无效，还可能掩盖真实瓶颈——比如高 %util 其实来自网络延迟或后端存储争抢，跟本地调度器毫无关系。
