linux没有文件级io调度算法，只有块设备级调度器（如mq-deadline、kyber、none），lsblk -d仅显示丢弃参数（disc-gran等），不读取/sys/block/*/queue/scheduler，故无法查看调度器；正确方法是cat /sys/block/设备名/queue/scheduler，方括号内为当前激活项。
Linux 没有“文件级”的 IO 调度算法，只有块设备级的调度器（如 mq-deadline、kyber、none），文件本身不绑定调度策略——调度发生在文件写入对应块设备（如 sda、nvme0n1）时。
为什么 lsblk -D 看不到调度算法
lsblk -D 只输出丢弃能力参数（DISC-GRAN、DISC-MAX、DISC-ZERO），和调度器完全无关。它不读取 /sys/block/*/queue/scheduler，也不暴露任何调度逻辑。
- 常见误操作：执行
lsblk -D | grep scheduler或期待它显示bfq—— 结果必为空 - 真正生效的调度器只存在于 sysfs 接口，且按物理设备隔离
- 若你查的是 LVM 逻辑卷（如
dm-0）或加密设备（luks-xxx），调度器实际作用在底层物理设备（如sda），dm-0/queue/scheduler通常不可读或只显示[none]
正确查看某块设备当前启用的调度器
必须指定设备名，并读取其 queue/scheduler 文件：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 先确认目标设备名：
lsblk -d（排除loop、zram、dm-等非物理设备） - 查
sda的调度器：cat /sys/block/sda/queue/scheduler，输出形如[mq-deadline] kyber bfq none，方括号内为当前激活项 - 查 NVMe 设备：
cat /sys/block/nvme0n1/queue/scheduler，多数情况显示[none]—— 这不是错误，是内核主动绕过软件调度层 - 如果该路径不存在或报
No such file or directory，说明设备驱动未暴露调度接口（常见于云盘如vda、某些 RAID 卡）
哪些设备能改、哪些不该动
不是所有设备都支持动态切换调度器，强行写入可能失败或被忽略：
-
nvme0n1显示[none]→ 写echo kyber > .../queue/scheduler多数会报Invalid argument，此时不用硬改 -
sda（SATA SSD）显示[cfq]或[deadline]→ 可尝试切到mq-deadline或none，但需验证是否真提升性能 - 根设备（如挂载
/的sda）临时切换后可能引发短暂卡顿，尤其在高 IO 场景下 - RAID 卡（如 MegaRAID）或某些旧 SATA 控制器驱动不支持
mq-deadline，写入后仍显示原值，说明内核拒绝了设置
调度器是运行时策略，不是文件属性；所谓“文件的 IO 调度算法”本质是“该文件所在文件系统所挂载的块设备的调度器”。最易被忽略的一点：混用 HDD 和 NVMe 时，elevator= GRUB 参数会统一作用于所有设备，无法差异化配置——这时得靠 udev 规则或手动脚本按设备名分别设置。
