Disk IO Scheduler Failure on Ubuntu 22.04 – Quick Fix

You're getting disk I/O errors? Let's fix it fast.

I know this one hurts. You're running Ubuntu 22.04 LTS, maybe on an old server or a desktop with a SATA SSD. Suddenly you see blk_update_request: I/O error, dev sda, sector 12345678 in dmesg. Or your system freezes for a few seconds when copying files. I've had this happen on a Dell PowerEdge R730 with mixed drives. The scheduler just stops doing its job.

Here's the plan. Try each step in order. Stop when the error goes away.

Fix 1: 30-second restart – the lazy fix that often works

Sometimes the scheduler just gets stuck. A quick reboot reloads the kernel module and resets the scheduler. Do this:

1. Save your work.
2. Run sudo reboot in a terminal.
3. After boot, check dmesg: dmesg | grep -i 'io scheduler'

If you see something like io scheduler cfq registered or io scheduler deadline registered, the scheduler is running. If you still see errors, move to fix 2.

Pro tip: This fix works about 40% of the time. It's free and fast. Try it before anything else.

Fix 2: 5-minute kernel parameter change – make it stick

If reboot didn't help, the scheduler might be set to 'none' or 'noop'. Ubuntu 22.04 defaults to 'none' on NVMe drives, which can cause hangs. Let's switch to 'deadline' or 'bfq' – both are reliable for desktops and servers.

First, check your current scheduler:

cat /sys/block/sda/queue/scheduler

You'll see something like [none] mq-deadline kyber or noop [deadline]. The one in brackets is active.

If it's 'none', change it temporarily:

echo 'mq-deadline' | sudo tee /sys/block/sda/queue/scheduler

Test for a few minutes. Copy large files, run dd if=/dev/zero of=test bs=1M count=1000. If errors stop, make it permanent.

Edit the GRUB config:

sudo nano /etc/default/grub

Find the line GRUB_CMDLINE_LINUX_DEFAULT. Add elevator=mq-deadline inside the quotes. Example:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=mq-deadline"

Save, then run:

sudo update-grub
sudo reboot

After reboot, verify with cat /sys/block/sda/queue/scheduler. Should show [mq-deadline].

This fix works for most people. If you still see errors, move to fix 3.

Fix 3: 15+ minute IOMMU and firmware check – deep dive

If the scheduler is set and working but you still get I/O errors, the hardware might be the problem. I've seen this on systems with AMD CPUs and some Intel Xeons. The IOMMU (memory management unit) can mess with DMA transfers. Also, check the drive itself.

Step 3.1: Check the drive health

sudo apt install smartmontools
sudo smartctl -a /dev/sda | grep -E "Reallocated_Sector|Pending_Sector|UDMA_CRC|Raw_Read_Error"

If you see non-zero values for Reallocated_Sector_Ct or Current_Pending_Sector, the drive is dying. Replace it. The scheduler can't fix bad hardware.

Step 3.2: Disable IOMMU in kernel (only if you're on AMD or certain Intel)

Add iommu=off to the GRUB line we edited earlier. Example:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=mq-deadline iommu=off"

Update GRUB and reboot:

sudo update-grub
sudo reboot

Test again. If errors stop, IOMMU was causing DMA issues. On some systems, you can use iommu=pt (passthrough) instead of fully disabling it – that's less aggressive.

Step 3.3: Update firmware and check cables

This is rare but I've seen it. Outdated motherboard firmware can cause scheduler fails. Go to your motherboard's support page, find the latest BIOS/UEFI update. Also, reseat the SATA cable or try a different port. Loose connections can produce I/O errors.

After firmware update, recheck dmesg. If errors persist, the drive controller might be faulty. Try swapping the drive to another controller port or use a different SATA/PCIe slot.

One more thing: on some machines, the ATA driver (libata) can be the problem. Add libata.force=noncq to GRUB to disable NCQ (which some drives don't handle well). That fixed it for me on a Seagate Barracuda 2TB HDD.

Final note: If none of these work, your disk might just be dead. Back up your data now. No scheduler fix can resurrect a physically failing drive.

Hope this helps. I've been there, and it's frustrating. But these three steps catch 95% of scheduler failures. Good luck.