山东省“One World One Health”学术会议在...

The best Linux I/O scheduler depends on the storage type and workload: 1. For NVMe/PCIe SSDs, use mq-deadline or none; 2. For SATA SSDs, use bfq or mq-deadline; 3. For HDDs in desktops, use bfq or deadline; 4. For HDDs in servers or databases, use deadline or mq-deadline; 5. In virtual machines, use none to let the host handle scheduling.

Linux I/O schedulers play a crucial role in determining how read and write operations are handled by storage devices. They sit between the filesystem and the block device layer, organizing and prioritizing I/O requests to optimize performance, fairness, and latency. Choosing the right I/O scheduler can significantly impact system behavior—especially under heavy disk load or with specific storage hardware.

Here’s what you need to know about the most common Linux I/O schedulers and when to use them.

What Does an I/O Scheduler Do?

An I/O scheduler (also called an elevator) manages the order in which I/O requests are sent to storage devices. Its goals include:

• Reducing disk seek time by merging and reordering requests.
• Improving throughput by batching similar operations.
• Balancing fairness among processes issuing I/O.
• Minimizing latency for time-sensitive operations.

Without an I/O scheduler, processes could generate chaotic, inefficient access patterns—especially on mechanical hard drives where physical head movement is slow.

Common Linux I/O Schedulers

Modern Linux kernels typically support several I/O schedulers. You can check which ones are available and currently active using:

cat /sys/block/sda/queue/scheduler

The output might look like:

[none] deadline cfq mq-deadline bfq

Here's a breakdown of the main schedulers:

1. noop – No Operation

• Best for: SSDs, NVMe drives, or systems with intelligent storage controllers (e.g., enterprise RAID arrays).
• How it works: Does minimal work—just merges adjacent requests. Leaves ordering largely up to the hardware or higher layers.
• Use case: When the underlying device handles scheduling better than the OS (common with fast storage).

Not typically used on general-purpose desktops or servers with HDDs.

2. deadline – Deadline-Based Scheduling

• Best for: Databases, real-time applications, or any workload sensitive to request latency.
• How it works: Assigns deadlines to read and write requests to prevent starvation. Prioritizes reads (usually more time-critical) and ensures no request waits too long.
• Key benefit: Predictable latency; avoids long delays even under heavy write load.

Widely used in production environments where responsiveness matters.

3. cfq – Completely Fair Queuing (Legacy)

• Best for: Multi-user systems or desktops with traditional HDDs (older kernels).
• How it works: Allocates time slices to each process issuing I/O, aiming for fairness.
• Downsides: High overhead, poor performance with SSDs or under heavy load. Deprecated in newer kernels (replaced by BFQ in many cases).

Avoid on modern systems unless required for compatibility.

4. bfq – Budget Fair Queuing

• Best for: Desktops, interactive workloads, or systems where responsiveness is key.
• How it works: Builds on CFQ’s fairness idea but uses a low-latency design. Assigns a "budget" of sectors to each process and services them one at a time.
• Advantages: Excellent for user interactivity—keeps the system snappy even during background I/O.
• Trade-off: Slightly lower throughput under heavy loads.

A good default choice for desktops using SATA SSDs or HDDs.

5. mq-deadline – Multiqueue Deadline Scheduler

• Best for: Modern hardware with multiqueue support (NVMe, high-end SSDs).
• Part of: The blk-mq (block multiqueue) framework introduced in Linux 4.0 .
• How it works: Scales deadline scheduling across multiple hardware queues. Maintains low latency and good throughput.
• Note: This is the successor to the old single-queue deadline scheduler in blk-mq-enabled systems.

Recommended for servers using fast storage and running recent kernels.

How to Change the I/O Scheduler

You can change the scheduler at runtime. For example, to set deadline for sda:

echo deadline > /sys/block/sda/queue/scheduler

To make it permanent, add kernel parameters at boot:

• For GRUB, edit /etc/default/grub and add:

  GRUB_CMDLINE_LINUX="elevator=deadline"

• Then regenerate the config:

  update-grub  # Debian/Ubuntu
  grub2-mkconfig -o /boot/grub2/grub.cfg  # RHEL/CentOS

  ---

  Which One Should You Use?

  Storage Type	Recommended Scheduler
  NVMe / PCIe SSD	mq-deadline or none
  SATA SSD	bfq or mq-deadline
  HDD (Desktop)	bfq or deadline
  HDD (Server/Database)	deadline or mq-deadline
  Virtual Machines	none (let host handle it)

  Tip: Monitor performance with tools like iostat, iotop, or blktrace after switching.

  ---

  Final Notes

  • The default scheduler depends on the kernel version and storage type. Modern kernels often auto-select based on whether the device is rotational (cat /sys/block/sda/queue/rotational).
  • With fast storage (SSDs/NVMe), the gains from aggressive scheduling are smaller—sometimes none or mq-deadline are sufficient.
  • Don’t assume one size fits all: test under real workloads.

  Basically, understanding I/O schedulers helps you match system behavior to your use case—whether it's a snappy desktop, a low-latency database, or a high-throughput server.

  The above is the detailed content of Understanding Linux I/O Schedulers. For more information, please follow other related articles on the PHP Chinese website!