如果取决于块设备的确切类型，那么每种类型设备的默认 I/O 调度程序是什么？
背景资料
Fedora 29 包含 4.19 系列的 Linux 内核。 （从技术上来说，最初的版本使用的是 4.18 系列内核。但是 4.19 内核是通过正常的软件更新安装的）。
从版本 4.19 开始，主线内核具有CONFIG_SCSI_MQ_DEFAULTas default y.也就是说，如果您采用 Linus 发布的树，而不应用任何特定于 Fedora 的补丁，就会得到这样的结果。默认情况下，SCSI 和 SATA 设备将使用新的多队列块层。 （Linux 将 SATA 设备视为 SCSI，使用基于SAT标准）。
这是删除旧代码的过渡步骤。所有旧代码现在都将被删除在版本中4.215.0，4.20 之后的下一个内核版本。
在新的 MQ 系统中，块设备使用一组新的 I/O 调度程序。这些包括none、mq-deadline、 和bfq。在主线4.19内核中，默认调度程序设置如下：
/* 对于 blk-mq 设备，我们默认对单队列设备使用 mq-deadline（如果可用）。如果截止日期不可用或者我们有多个队列，则默认为“无”。 */
有人建议使用 BFQ 作为默认值来代替mq-deadline. 4.19 版未接受此建议。
对于传统的SQ块层，默认调度器是CFQ，它与BFQ最相似。
=> 内核的默认 I/O 调度程序可能会有所不同，具体取决于设备类型：SCSI/SATA、MMC/eMMC 等。
CFQ 尝试支持某种程度的“公平”和 I/O 优先级 ( ionice)。它具有各种复杂性。 BFQ 就更复杂了；它支持ionice但也具有自动对某些 I/O 进行分类和优先级的启发式方法。 deadline风格调度更简单；它ionice根本 不支持。
=> 具有 Linux 默认内核配置、SATA 设备且没有其他用户空间策略（例如，无udev规则）的用户将在 4.19 中发生行为更改。曾经起作用的地方ionice，将不再有任何作用。
然而，Fedora 包含特定的内核补丁/配置。 Fedora 还包括用户空间策略，例如默认udev规则。
Fedora Workstation 29 使用什么作为默认 I/O 调度程序？如果取决于块设备的确切类型，那么每种类型设备的默认 I/O 调度程序是什么？
答案1
Fedora 29 附带2016年4月18日核心。看来 CFQ 是默认值。
$ grep CONFIG_DEFAULT_IOSCHED= /boot/config-4.18.16-300.fc29.x86_64
CONFIG_DEFAULT_IOSCHED="cfq"
$ grep CONFIG_SCSI_MQ_DEFAULT /boot/config-4.18.16-300.fc29.x86_64
# CONFIG_SCSI_MQ_DEFAULT is not set
$ cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
截至撰写本文时（2018 年 11 月 24 日），4.19.3作为 F29 的更新提供。但是，配置选项似乎没有改变。
4.20.0 (RC1) 位于“Rawide”开发树中。在那个开发树内核中，CFQ 是仍然默认值，并且CONFIG_SCSI_MQ_DEFAULT尚未设置。 Fedora 内核列表位于https://lists.fedoraproject.org/archives/list/[电子邮件受保护]/是讨论这种情况是否应该改变的最佳场所。
答案2
一些可能对您的选择有用的信息
我是 BFQ 的作者之一，所以我几乎是一个无私的一方:)但我只会报告通过可重复测试获得的数字。
我们一直在 SD 卡、eMMC、HDD、SATA SSD 和 NVMe SSD 上测试 BFQ。对于 HDD 和 SSD，我们已经使用单磁盘和 RAID 配置进行了测试。
就吞吐量而言，结果可总结如下。对于 SD 卡、eMMC 和 HDD（单个和 RAID），吞吐量不会下降。相比之下，使用 HDD 时，在某些工作负载下可实现约 20-30% 的增益。
在 SSD 上，仅存在吞吐量损失
- 使用随机同步 I/O：平均 SSD 约为 2-3%，非常快的 NVMe SSD 高达 10-15%。由于工作负载旨在将 BFQ 置于最困难的条件下，我们的损失达到了 18% [1]，但在任何其他第三方测试中，最坏情况下的损失约为 10%。这种损失主要是由于 BFQ 不是一个最小 I/O 调度器。我们正在努力解决这个问题。这不简单;我们需要时间来填补这一空白。
- 在非常快的 SSD 上仅写入 I/O：大约 5-10%。这是由于 I/O 请求标签的问题造成的。我们已经找到了解决方案。由于我们认为这个问题并不重要，因此我们更加优先考虑待办事项列表中的其他项目。如果您不这么认为，我们愿意改变我们的优先事项。
由于上述开销，BFQ 无法在商用 CPU 上处理超过 400-500 KIOPS。
就时间敏感应用程序（例如音频/视频播放器）的响应能力和延迟而言，结果是无与伦比的。例如，无论后台的 I/O 工作负载如何，BFQ 应用程序的启动速度就像驱动器空闲一样。使用任何其他调度程序，应用程序可能需要十倍的时间，甚至根本无法启动（直到后台工作负载结束）[1]。
此外，对于类似服务器的工作负载，BFQ 可以保证每个客户端（或容器、VM 或任何其他类型的实体共享存储）所需的 I/O 带宽比例，同时达到总带宽。吞吐量无法与任何其他控制 I/O 的解决方案所达到的吞吐量相比 [2]。
最后，如果您对某些特定的工作负载有疑问，我们将很乐意对其进行测试。
[1]http://algo.ing.unimo.it/people/paolo/disk_sched/results.php