Linux Disk Error Checking: Diagnosis and Repair

What Does Error EIO / I/O Error Mean

An Input/Output Error in Linux manifests as the system code EIO or I/O error messages in logs. The operating system receives this signal from the disk driver when it cannot read or write data to the specified block.

In practice, this looks like: the system "freezes" when accessing files, the file system automatically switches to "read-only" mode, and warnings like kernel: EXT4-fs error or Buffer I/O error appear in the terminal. The system may not necessarily crash immediately, but further use of the corrupted partition without diagnostics leads to file loss.

Common Causes

1. Physical drive wear. HDDs develop bad sectors due to scratches on platters or degradation of the magnetic layer. On SSDs, NAND memory cells reach their endurance limit or the controller fails.
2. Poor contact or cable damage. A loose SATA cable, a bent M.2 card, or a power connector issue disrupts data transfer at the hardware level.
3. Sudden power loss. An unexpected power outage or forced reboot doesn't give the system time to properly close file descriptors, breaking the file system's metadata structure (superblock, journal).
4. Driver or kernel conflict. An outdated or incompatible ahci/nvme controller driver may mishandle DMA commands, triggering false error conditions.

Solutions

Method 1: Diagnosis via System Logs

Before taking active measures, identify which specific drive is causing the problem. The kernel log maintains a history of hardware accesses.

1. Open a terminal and run:

dmesg | grep -iE 'error|fail|bad|sector' | tail -n 50

This command outputs the last 50 lines containing key error keywords. Note the device name, such as sda1, nvme0n1p2, or mmcblk0.

2. Check current disk errors using the smartctl utility:

sudo smartctl -l error /dev/sdX

Replace /dev/sdX with your disk. If the output is empty or contains only old records, the cause is likely file system corruption.

💡 Tip: Use lsblk -f to quickly map device names (/dev/sda) to mount points (/home).

Method 2: Physical Health Check (SMART)

S.M.A.R.T. attributes provide a clear picture of drive health. Install the package if it's missing:

sudo apt install smartmontools   # Debian/Ubuntu
sudo dnf install smartmontools   # RHEL/Fedora

Run a full diagnostic:

sudo smartctl -a /dev/sdX

Carefully review the SMART overall-health self-assessment test result line. If the status is PASSED, the disk is physically sound. Critical attributes:

• Reallocated_Sector_Ct: count of reallocated sectors. A value above 100 requires attention.
• Current_Pending_Sector: sectors waiting for reallocation. Indicates beginning degradation.
• UDMA_CRC_Error_Count: SATA cable transfer errors. If the counter is rising—replace the cable.

Method 3: File System Check and Repair

If SMART is healthy, the issue lies in the logical structure. The fsck (File System Consistency Check) utility fixes metadata inconsistencies.

1. Unmount the partition. Checking a mounted file system is dangerous:

sudo umount /dev/sdXY

If the disk is system-critical and won't unmount, boot from a LiveUSB or wait for an automatic check on the next reboot.

2. Run the check with automatic confirmation:

sudo fsck -y /dev/sdXY

The -y flag answers 'yes' to all repair prompts. The process can take from a few seconds to an hour, depending on volume and drive speed.

3. Check the result:

echo $?

An exit code 0 means no errors found. Codes 1 or 2 indicate successfully fixed issues. Codes above 4 require manual intervention or drive replacement.

4. Remount the partition or reboot the system:

sudo mount -a

Prevention

• Regularly check SMART. Configure automated tests via smartd. Enable the service and add a rule in /etc/smartd.conf to monitor critical attributes.
• Use a UPS. Sudden voltage spikes are the primary cause of journal corruption on ext4/btrfs.
• Monitor temperature. HDD overheating above 50°C accelerates read/write head wear. Ensure proper case airflow and monitor readings with hddtemp or smartctl -A.
• Back up data. Disk errors often escalate rapidly. Store critical data on separate media or in the cloud using rsync or borgbackup.