Disk errors in Linux can lead to slow applications, kernel warnings, and permanent data loss if they go unnoticed. Regular checks on attached disks catch failing hardware and filesystem inconsistencies before they corrupt important data or bring services down.

Block devices expose disks and partitions under paths like /dev/sda and /dev/sdb1, which tools can probe at both the hardware and filesystem levels. Utilities such as lsblk show how these devices map to mount points, smartctl queries S.M.A.R.T. attributes from the drive firmware, fsck validates on-disk filesystem metadata, and badblocks performs sequential reads to locate sectors that no longer return clean data.

Thorough checks require taking filesystems offline so no writes occur while metadata repairs or bad-block scans are in progress. On systems where a disk holds the root or boot filesystem, checks are best performed from a live Linux environment or rescue mode. Heavy scans can run for hours on large disks, and misidentifying the target device can destroy data, so device names and mount points from lsblk should be verified carefully before starting maintenance.

Steps to check disk errors in Linux:

  1. Open a terminal with access to sudo privileges.
  2. List available disks to identify the device name for the disk that requires checking.
    $ lsblk
    NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    loop0    7:0    0 55.4M  1 loop /snap/core18/1997
    loop1    7:1    0  219M  1 loop /snap/gnome-3-34-1804/66
    loop2    7:2    0 64.8M  1 loop /snap/gtk-common-themes/1514
    loop3    7:3    0 32.3M  1 loop /snap/snapd/11588
    loop4    7:4    0   51M  1 loop /snap/snap-store/518
    loop5    7:5    0 65.1M  1 loop /snap/gtk-common-themes/1515
    sda      8:0    0   20G  0 disk 
    ├─sda1   8:1    0    1M  0 part 
    ├─sda2   8:2    0  513M  0 part /boot/efi
    └─sda3   8:3    0 19.5G  0 part /
    sdb      8:16   0   20G  0 disk /mnt/data
    sr0     11:0    1 1024M  0 rom

    Use the NAME and MOUNTPOINT columns to correlate devices like sdb with their filesystems and mount points.

  3. Unmount the filesystem on the target disk or partition so no data is being written during testing.
    $ sudo umount /dev/sdb
    [sudo] password for user:

    Replace sdb with the correct disk or partition, such as sdb1, and ensure no processes are using the mount point before unmounting.

  4. Check the disk's S.M.A.R.T. overall health status using smartctl.
    $ sudo smartctl -H /dev/sdb
    smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.11.0-16-generic] (local build)
    Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
    
    === START OF READ SMART DATA SECTION ===
    SMART Health Status: OK

    SMART Health Status: OK indicates that the drive firmware reports no critical hardware problems, but filesystem checks are still recommended.

  5. Run fsck on the disk or partition to check and repair filesystem-level inconsistencies.
    $ sudo fsck /dev/sdb
    fsck from util-linux 2.36.1
    E2fsck 1.45.7 (28-Jan-2021)
    /dev/sdb: clean, 11/1310720 files, 126322/5242880 blocks

    Running fsck on a mounted or actively used filesystem can corrupt data; always unmount the filesystem first or use a live environment for root and boot partitions.

  6. Scan the disk for bad blocks using badblocks in read-only mode.
    $ sudo badblocks -v /dev/sdb
    Checking blocks 0 to 20971519
    Checking for bad blocks (read-only test): done                                                 
    Pass completed, 0 bad blocks found. (0/0/0 errors)

    Read-only scans avoid overwriting data but can still take many hours on large disks; avoid the -w option unless data is fully backed up because it performs destructive write testing.

  7. Remount the disk once all checks have completed without errors.
    $ sudo mount /dev/sdb /mnt/data

    Adjust the device and mount point so they match the original mapping, for example mounting sdb1 back on /mnt/data or another appropriate directory.

  8. Verify that the disk is mounted correctly and visible at the expected mount point.
    $ df -h /mnt/data
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sdb         20G  1.5G   18G   8% /mnt/data

    Confirm that the Mounted on column shows the expected path (such as /mnt/data) and that the reported size matches the disk identified earlier with lsblk.