Linux实时查看磁盘IO调度策略的方法

查看 Linux 磁盘 IO 调度策略时，必须先确定具体设备名称，然后使用sudo cat /sys/block/设备名/queue/scheduler进行查询；输出中方括号包裹的内容就是当前正在使用的调度器。如果 NVMe 设备或云服务器云盘显示为[none]，这通常是正常现象，既不用额外配置，也没有必要强行修改。

怎么查某块盘当前用的 IO 调度器

在 Linux 系统中，并没有统一的“全局磁盘调度策略”；每个块设备（例如 sda、nvme0n1）都拥有各自独立的 IO 调度配置。因此，想准确查看当前磁盘 IO 调度器，必须指定到具体设备。最直接的方法就是读取 /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

如果执行 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 失败的常见原因

虽然 Linux 支持在运行时切换部分磁盘 IO 调度器，但实际写入失败的情况并不少见，常见原因大多与设备支持项或命令写法有关：

• 只能写入 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 怎么办

在云服务器环境中，如果查询不到 scheduler，很多时候并不是操作有误，而是云厂商有意隐藏或禁用了该接口。像阿里云云盘、AWS EBS、腾讯云 CBS 等常见云存储，普遍都存在这种情况：

• 执行 cat /sys/block/vda/queue/scheduler 可能只返回 [none]，也可能直接报错 No such file or directory
• 云服务商通常已经在存储网关层完成了调度优化，如果再向用户暴露内核 IO 调度器，反而可能干扰整体 I/O 路径，因此会直接关闭或屏蔽该能力
• 这时不必继续折腾 elevator= 启动参数——即使在 GRUB 中添加，多数情况下也不会生效，启动日志里常会看到类似 elevator: ignoring, not supported 的提示
• 判断云盘实际性能，更应结合 iostat -xk 1 与 dd iflag=direct 做实测分析，而不是只看调度器名称