Linux kernel · Event blk_update_request: I/O error

blk_update_request: a read or write to a disk failed

The kernel asked a block device for a sector and did not get it. This is the lowest-level storage failure Linux reports, below any filesystem — so it is real, it is not a software bug, and the only question left is whether the drive, the cable, or the layer beneath it is at fault.

Also written as blk_update_request I/O errorBuffer I/O error on devlinux disk read error dmesg

How oftenUncommon
Vendor calls itkern.err
Logkern
Sourcekernel

What it means for you

On a personal computer

Your computer tried to read or write part of a disk and could not. This is not a program crashing — it is the storage itself refusing. If the device is your main drive, copy anything you care about off it now, before doing anything else. If it is a USB stick or an SD card, those fail like this routinely and cheaply.

For an analyst

Read the operation, the sector, and the device together before deciding. A single read error at a fixed sector is a media defect and will follow the data; errors scattered across sectors, or against a device with no bad-sector growth, point at the transport — cable, expander, HBA, or in a VM the storage path underneath. In cloud and virtualised environments this frequently means the hypervisor's storage stalled, not that any disk is bad, and the guest cannot tell the difference.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample

Sep  7 03:12:44 db-01 kernel: [284561.882014] blk_update_request: critical medium error, dev sda, sector 509075752 op 0x0:(READ) flags 0x84700 phys_seg 1 prio class 0
Sep  7 03:12:44 db-01 kernel: [284561.882031] Buffer I/O error on dev sda1, logical block 63634211, async page read

The fields that decide it

Everything else in the log line is context.

dev: Which block device. Note that this is the kernel's name at that moment — device names are not stable across reboots, so record the serial number from `lsblk -o NAME,SERIAL` while the machine is still up.
op / operation: What was being attempted.
sector: The logical sector that failed. Sector 0 is the partition table and is disproportionately bad news. Two conversions trip people up when mapping it to a file: the kernel prints 512-byte sectors while the filesystem counts in its own block size, and the kernel's sector is relative to the whole device while the filesystem's block is relative to the partition — so subtract the partition's start offset from `fdisk -l` first.
Accompanying lines: This message rarely appears alone, and the neighbours carry the diagnosis. 'Buffer I/O error on dev' is the layer above reporting the same failure. A SCSI 'Sense Key : Medium Error' means the drive itself says the sector is unreadable; 'Hardware Error' or a link reset points at the path instead.
Repetition: A slowly growing count against one sector is a dying region of a disk. A sudden burst across many sectors is usually a cable, controller, or storage-path event rather than the media.

Ordinary reasons this happens

Most of the time it is one of these.

A USB stick, SD card, or cheap external drive reaching the end of its life. These fail this way constantly and it says nothing about the machine.
A device removed while still mounted, which produces a burst of errors and then silence.
A virtual machine whose datastore stalled or failed over, where the guest times out and reports errors against a disk that is perfectly healthy.
Loop devices and thin-provisioned volumes reporting unsupported operations such as WRITE_ZEROES or DISCARD.
An optical drive or a card reader with no media in it, which some drivers report as I/O errors rather than as an empty device.

When it is not ordinary

Destructive wiping of a device, which produces write errors once the target is partially destroyed.

What gives it awayA burst of write errors against a device that was healthy minutes earlier, alongside process activity writing directly to /dev/sd* rather than through a filesystem.

ATT&CK T1561.001

Ransomware or a wiper triggering errors on a device it is overwriting faster than the device can absorb.

What gives it awayErrors correlating with a process holding the raw device open, and with a sharp rise in write throughput to a device that is not normally written to.

ATT&CK T1485

What to do next

Copy your data off first if the device holds anything you need. Diagnosis can wait; a marginal disk gets worse with every access.
Identify the device properly, by serial rather than by name: `lsblk -o NAME,SERIAL,MODEL,SIZE,MOUNTPOINT`.
Read the surrounding kernel lines. `dmesg -T | grep -A5 -B5 blk_update_request` — the SCSI sense data next to the error is what distinguishes a media defect from a link problem.
Get the drive's own opinion: `smartctl -a /dev/sdX`. Reallocated_Sector_Ct, Current_Pending_Sector, and Offline_Uncorrectable rising over time is the drive telling you it is failing.
Run a non-destructive self-test: `smartctl -t long /dev/sdX`, then read the result some hours later. It will find unreadable sectors the filesystem has not touched yet.
If SMART is clean, suspect the path. Swap the cable, move to a different port or backplane slot, and check for link resets in dmesg — `ata` link errors and controller resets are the signature.
In a VM, check the hypervisor before the guest. The guest cannot distinguish a stalled datastore from a bad disk, and the answer is usually not in the guest.
Once the device is safe, `fsck` the filesystem — but only after the underlying storage is stable, because running a repair against a failing disk can turn a recoverable situation into an unrecoverable one.

Queries to run

grep The errors with their surrounding context, with human-readable timestamps.

dmesg -T | grep -E 'blk_update_request|Buffer I/O error|Sense Key|I/O error, dev'

grep Kernel messages at error level for the past week. Storage failures are usually not the only thing here, and the neighbours matter.

journalctl -k -p err --since '7 days ago'

grep The drive's own verdict. Rising pending and reallocated sector counts are the numbers that decide whether to replace it.

smartctl -a /dev/sda | grep -E 'Reallocated|Pending|Uncorrectable|Power_On_Hours|SMART overall-health'

grep How many failures there have been, and which physical device they belong to — recorded by serial so it survives a reboot renaming the device.

grep -c 'blk_update_request' /var/log/kern.log; lsblk -o NAME,SERIAL,MODEL,MOUNTPOINT

Common questions

Does 'blk_update_request: I/O error' mean my disk is dying?

Often, but not always — and the distinction is worth ten minutes. The message means a read or write to the device failed after the kernel's retries. If it is a 'critical medium error' at a consistent sector and SMART shows pending or reallocated sectors climbing, the drive is failing. If SMART is clean and the errors are scattered or bursty, suspect the cable, the controller, or — in a virtual machine — the storage underneath the hypervisor.

What should I do first when I see this error?

Back up. Every subsequent step involves reading the device, and a marginal drive degrades with use. Copy what matters off before running fsck, before a SMART long test, and before rebooting — a machine with a failing boot disk may not come back up, and that is a much worse position to be in.

How do I find out which file the bad sector belongs to?

Three steps, and the middle one is the one people miss. Subtract the partition's start sector (from `fdisk -l`) from the sector in the message, because the kernel counts from the start of the device and the filesystem counts from the start of the partition. Then divide by eight to convert 512-byte sectors to 4096-byte filesystem blocks. Then run `debugfs -R "icheck <block>" /dev/sdXN` for an inode and `debugfs -R "ncheck <inode>" /dev/sdXN` for the filename. If icheck returns nothing, the block belongs to filesystem metadata rather than a file, which is a worse answer than a lost file.

Why do I get I/O errors in a virtual machine when the underlying storage is fine?

Because the guest cannot see the storage stack it is actually running on. If the datastore stalls, a path fails over, or a snapshot operation blocks I/O for longer than the guest's timeout, the guest kernel concludes the disk did not answer and reports an I/O error. Look at the hypervisor's own logs before doing anything to the guest — replacing a virtual disk that was never faulty is a common and wasted afternoon.

Vendor documentation

Last reviewed 7 September 2026