先确认设备名（如sda），再执行cat /sys/block/sda/queue/scheduler查看，输出中方括号内即为当前激活的io调度器；nvme设备显示[none]属正常，表示绕过软件调度层，不可强行修改。
怎么查当前设备用的IO调度器
Linux不按“系统”统一设IO策略，而是每个块设备（如sda、nvme0n1）单独配置。直接跑cat /sys/block/sda/queue/scheduler就能看到它当前用哪个——输出形如[deadline] cfq noop，方括号里那个就是激活项。
常见陷阱：
- 没确认设备名就乱填：先用
lsblk或cat /proc/partitions筛出真实物理盘（避开loop、md、dm-这类逻辑层） - 看到
[none]就以为出错：NVMe设备在较新内核下默认绕过传统调度层，none是正常状态，不代表失效，也不支持改写 - 对
vda（云盘）执行该命令：阿里云、AWS等平台通常屏蔽控制权，/sys/block/vda/queue/scheduler只显示[none]且写入会失败
为什么echo deadline > /sys/block/sda/queue/scheduler失败
运行时切换必须满足三个硬条件，缺一不可：
- root权限：普通用户写入直接
Permission denied，得用sudo sh -c 'echo deadline > ...' - 目标调度器在当前设备支持列表里：比如某些NVMe驱动不认
cfq，写进去仍显示[none]，不是命令错，是硬件不支持 - 没被内核锁死：部分RAID卡或LVM底层设备会禁用调度器切换，写入后报
Invalid argument，此时只能查厂商文档
别对根设备（如正在挂载/的sda）激进测试——从cfq切到noop可能引发瞬时卡顿，尤其在高负载时。
怎么让IO策略重启后还生效
靠内核启动参数elevator=xxx，不是改配置文件也不是systemd服务：
- 编辑
/etc/default/grub，找到GRUB_CMDLINE_LINUX_DEFAULT行，在引号内加elevator=deadline（注意空格分隔） - Debian/Ubuntu执行
sudo update-grub；RHEL/CentOS执行sudo grub2-mkconfig -o /boot/grub2/grub.cfg - 重启才生效；若改错导致无法进系统，需在GRUB启动菜单按
e临时删掉elevator=参数
这个参数对所有块设备统一生效，没法给SSD和HDD分别指定不同策略——现代SSD/NVMe固件已做深度优化，内核调度反而可能拖慢性能，多数场景下保持none或noop更稳。
哪些IO指标能反推调度器是否起作用
调度器效果得结合实际IO行为看，不能光看/sys/block/xxx/queue/scheduler里写了啥：
- 用
iostat -x 1观察await（平均IO等待时间）和%util（设备忙时占比）：如果%util长期接近100%但await飙升，说明队列堆积，可能是调度器没压住请求 - 对比
rrqm/s（读合并数）和wrqm/s（写合并数）：deadline会主动合并相邻IO，值明显高于noop；但SSD随机IO延迟低，合并收益小，数值差异可能不显著 - 别依赖
vmstat的wa（IO等待CPU%）：它反映的是CPU在等IO完成，跟调度器是否高效无直接关系
真正关键的是设备本身特性——NVMe默认none不是缺陷，而是设计使然；强行覆盖反而可能干扰固件调度逻辑。
