直接执行cat /sys/block/sda/queue/scheduler（sda替换为实际设备名），输出中方括号内标识者即当前生效的io调度器，如[mq-deadline] kyber bfq none中的mq-deadline。
怎么确认当前磁盘用的是哪个IO调度器
直接读取内核暴露的接口最可靠，别信文档或发行版默认值——实际运行时可能已被改过。
- 执行
cat /sys/block/sda/queue/scheduler（把sda换成你的真实设备名），输出类似mq-deadline kyber [bfq] none，方括号里就是当前激活的调度器 - 如果看到
[none]，说明内核跳过了IO调度，直接交由设备处理；[mq-deadline]是目前多数SSD/NVMe的默认，[bfq]多见于桌面或混合负载场景 - 注意：不同内核版本支持的调度器不同，
kyber在 5.0+ 才稳定，cfq在 4.12+ 已被移除，别在新系统里找它
大文件读写时，哪些指标能反映调度器是否起作用
不能只看吞吐量（rkB/s 或 wkB/s），大文件顺序IO下多数调度器差异不大；真正暴露调度器效果的是延迟和队列行为。
-
await和avgqu-sz要一起看：如果await稳定在 1ms 以下（SSD）但avgqu-sz长期 > 8，说明调度器在主动积压请求做合并，mq-deadline或kyber就在按设计工作；而none下avgqu-sz通常更低、await更抖 - 用
iostat -xk 1 -p sda（不是-p ALL）盯单个设备，避免LVM或RAID层干扰；重点观察r_await是否随读大小变化——bfq对小块读更敏感，mq-deadline在 128KB+ 大块读时延迟更稳 - 别依赖
%util：大文件写入时它常接近 100%，但这只是设备忙，不等于调度器在优化；反而svctm已被废弃，新版内核不更新，直接忽略
怎么对比不同调度器对大文件IO的实际影响
临时切换 + 控制变量测试是唯一可信方式，别靠理论猜。重点防两个坑：缓存干扰和测试方法失真。
- 测试前清缓存：
sync && echo 3 | sudo tee /proc/sys/vm/drop_caches，否则dd读的是 page cache，测不到真实磁盘调度效果 - 用 direct I/O 绕过缓存：
dd if=/dev/zero of=/mnt/test.bin bs=1M count=2048 oflag=direct，再用dd if=/mnt/test.bin of=/dev/null iflag=direct bs=1M；加oflag=direct和iflag=direct是关键，否则全走缓存，调度器根本没机会介入 - 每次换调度器后至少跑 3 轮测试，取
await和rkB/s的中位数；单次dd时间不准，iostat -xk 1的滚动平均才反映持续负载下的调度行为 - 注意设备类型：HDD 上
mq-deadline和bfq延迟差异明显；NVMe 上none和kyber吞吐几乎一样，但kyber的r_await标准差更小，适合延迟敏感业务
为什么改了调度器，iostat 看不出变化
常见原因是测试场景没触发调度器的核心逻辑——它主要优化请求合并与排序，而大文件顺序IO本身就不需要频繁寻道或重排。
- 调度器对大文件读写的“优化”往往体现在突发负载下：比如同时有日志写 + 备份读 + 数据库刷盘，这时
mq-deadline会优先保障读请求不超时，bfq则可能让备份进程饿死 - 单纯跑
dd测大文件，本质是单一流、无竞争、无随机性，连noop都够用；真要验证效果，得用fio模拟混合负载：fio --name=readwrite --ioengine=libaio --rw=randread:randwrite --bs=4k --numjobs=8 --runtime=60 - 检查是否改对了设备：LVM 或 RAID 卷有自己的队列，
/sys/block/mapper/vg-lv/queue/scheduler可能和物理盘sda不一致；lsblk看清楚挂载点对应的真实底层设备
