必须先指定设备名，然后用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 读取，普通用户执行会失败。不是权限配置问题，是内核强制限制：
- 必须加
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 卡或旧内核（<5.0）不支持
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 其实来自网络延迟或后端存储争抢，跟本地调度器毫无关系。 
