I created the LinuxTweaks IO-Scheduler Tweak because I kept seeing people running with default kernel schedulers that weren’t optimized for their hardware. Most Linux distros ship with one-size-fits-all defaults, and it’s killing performance on everything from NVMe drives to old spinning disks. This script lets you fix it in about two minutes.

What’s an IO Scheduler Anyway?

Your Linux kernel needs to decide the order it sends read/write requests to your storage device. That’s what an IO scheduler does. Different schedulers have different strategies, and picking the right one for your hardware can make a real difference in how responsive your system feels.

The Schedulers Explained (2026)

BFQ (Budget Fair Queueing)

BFQ is the current workhorse for most desktops and laptops. It prioritizes fairness and interactivity over pure throughput. If you’re doing desktop work – opening apps, moving files around, just general computing – BFQ keeps your system snappy. It works well for both SATA SSDs and mechanical drives because it understands that humans care about responsiveness, not theoretical maximum bandwidth. For 2026, BFQ is still the best choice for interactive workloads.

MQ-Deadline

This scheduler ensures that requests don’t get starved. It combines a deadline queue with a sorted queue, making sure nothing gets ignored. It’s decent for server workloads where fairness matters, but for desktop use it’s overkill. Most people switching to MQ-Deadline from the defaults feel no real difference. It’s available and works, but it’s not optimal for anything modern.

None (NVMe)

When you set a scheduler to “none”, the kernel doesn’t queue or reorder requests. They go straight to the device. NVMe drives are designed to handle this themselves. They have their own internal queues, intelligent schedulers built into the firmware, and thousands of IOPS available. Letting the kernel reorder requests actually makes things worse. With NVMe, “none” lets the device do what it was built to do. This has been the recommendation since NVMe became mainstream, and it’s still true in 2026.

Kyber

Kyber is designed for low latency devices, particularly NVMe. It tracks latency and adjusts queue depth dynamically. If you have a high-end NVMe drive and care about latency, Kyber can be good. But most people won’t notice the difference between Kyber and “none” on their NVMe. It’s a niche choice.

The list of available schedulers you can check via the next command (the current scheduler is allocated in square brackets): cat /sys/block/sda/queue/scheduler

Why You Should Care About This

Modern Linux systems come with defaults that were reasonable when SSDs were still catching on. Now that everyone’s using SSDs or NVMe, those defaults are costing you. A drive that could give you better responsiveness is being hampered by a scheduler that assumes you need perfect fairness between background tasks and foreground work. You don’t. You want your interactive commands to feel fast.

The LinuxTweaks script autodetects your hardware and sets the right scheduler. NVMe gets “none”. SATA SSD gets “bfq”. Mechanical drives get “bfq”. No guessing, no manual tweaking of sysctl files.

Systemd Service vs Udev Rule: Which One?

The script gives you two ways to persist the change across reboots.

Systemd Service

A systemd service runs a one-shot command that echoes the scheduler name into the sysfs file. It happens at boot time, after filesystems are mounted. It’s straightforward – your system starts up, the service runs, the scheduler is set. If you want to see what’s happening during boot, you can check the service status. Systemd services are reliable and clear about what they do. This is the recommended method for most people.

Udev Rule

Udev rules run when a device appears. When the kernel discovers your drive, udev matches it against your rules and sets the scheduler immediately. No waiting for a boot service to run. Udev is faster and more direct. The drawback is less visibility – udev rules run silently. If the rule doesn’t work, it’s harder to debug. For production servers or if you like the most direct approach, udev is solid. For most users, systemd is simpler.

I recommend systemd service. It’s easier to troubleshoot if something goes wrong, and the performance difference is negligible for a one-time boot operation.

What This Script Saves You

Without this script, you’re looking at manual sysctl configuration or editing boot parameters. You’d need to know which scheduler is which, understand the differences, make an educated guess about your hardware, and handle persistence yourself. The script does all that. It’s five dialogs instead of hours of research and manual work.

Further Reading

If you want the deep technical dive on every scheduler, kernel documentation covers all current options. A good reference is the Linux kernel documentation at https://www.kernel.org/doc/html/latest/block/index.html – specifically the scheduler sections explain the internals of each algorithm.

The reason I built this was simple: optimization shouldn’t require expertise. Your system should just work better when you run it.

• Tolga Erok