Stumbling to your desk and logging into the remote management console, you are greeted not by a familiar login screen, but by the cold, unforgiving prompt of an emergency recovery shell:

Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.
:/# _

Your pulse quickens as the reality sets in: the server has refused to boot because its storage system is damaged, and millions of pounds of transaction history hang in the balance. In this high-stakes moment between total data loss and system recovery, Linux administrators rely on a fundamental, time-tested tool: fsck (File System Consistency Check). Acting as an automated forensic surgeon, fsck inspects the underlying map of your storage drive, identifies broken links and corrupted markers, and methodically reconstructs the filesystem into a healthy state.

When confronted with a broken drive, the single most critical command you can run—before attempting any dangerous automated repairs—is a safe, non-destructive diagnostic audit:

sudo fsck.ext4 -fnv -C 0 /dev/sdb1

This command is your digital safety net. The -f flag forces a thorough check even if the drive claims to be clean; -n ensures the disk is opened strictly in read-only mode so that not a single byte is altered; -v provides detailed diagnostic output; and -C 0 displays a real-time progress bar. Running this audit allows you to assess the exact extent of the structural damage before committing to permanent changes.

What It Does in Plain English

Think of a filesystem as a vast public library. The storage drive is the building with millions of physical shelves (data blocks), while the catalogue cards (known as inodes) record which book belongs on which shelf, who owns it, and where the index points.

When power cuts out unexpectedly or hardware falters, books might be left on desks without being logged, or the index might record two completely different books sitting on the exact same shelf.

At its core, fsck acts as the chief auditor. It walks through the raw binary records of filesystems such as Ext4, XFS, or Btrfs, verifying that every single directory, file record, and storage block obeys strict mathematical rules. When it discovers contradictions, fsck severs broken links, gathers orphaned data into a recovery area, and rebuilds the library catalogue so the system can run safely once more.

The Architecture of Filesystem Validation

To wield fsck effectively during a production outage, an engineer needs to understand how modern Linux filesystems—most notably the Ext4 standard—organise their data, and how fsck validates storage across five distinct algorithmic passes.

Superblock Topology and Sparse Superblock Geometry

An Ext4 filesystem is segmented into multiple contiguous sections called Block Groups, as detailed in the Linux Kernel Ext4 Filesystem Documentation. The master control record governing the entire drive is the Superblock, located at byte offset 1024. The Superblock records global parameters: total inode count, block count, block size (typically 4096 bytes), volume UUID, and status flags (0x0001 for Cleanly Unmounted, 0x0002 for Errors Detected).

Because a single damaged sector at the start of a drive could instantly render an entire multi-terabyte volume unreadable, Linux uses Sparse Superblock Geometry (sparse_super). Rather than copying the superblock to every block group (which degrades performance), backup copies of the superblock and descriptor tables are stored in: - Block Group 0 (Primary Superblock) - Block Group 1 - Block Groups that are powers of 3, 5, and 7 (e.g., Groups 3, 5, 7, 9, 25, 27, 49, 81...)

If an errant storage controller corrupts Block Group 0, fsck can restore the entire filesystem using one of these deterministic backup locations.

JBD2 Journal Replay Mechanics

Modern filesystems avoid structural corruption during unexpected shutdowns using the Journaling Block Device (JBD2) layer. When an application requests a file modification, the kernel first records the intended metadata changes as an atomic transaction in a dedicated ring-buffer area called the journal inode (typically Inode 8).

A JBD2 transaction moves through four stages: 1. Running: Actively accepting new descriptor updates from the kernel. 2. Locked: Closed to new changes; preparing to commit. 3. Flushing: Writing all descriptor blocks and payloads into the on-disk journal. 4. Commit: Writing a final commit record with a cryptographic checksum.

When e2fsck initialises against an unmounted filesystem tagged with the NEEDS_RECOVERY flag, it inspects the journal pointers. If valid commit blocks exist from before the crash, e2fsck replays the journal—writing the pending transactions directly into the inode tables and block maps. Once completed, the volume is marked clean. If the journal contains corrupted transactions or truncated records, the journal is discarded (e2fsck -E journal_only), triggering a full 5-pass consistency scan.

The Five Standard Check Passes of e2fsck

When a full scan is required, e2fsck executes a structured, multi-pass pipeline:

• Pass 1: Checking Inodes, Blocks, and Sizes
  The utility reads the raw inode table across every block group. It validates file types, verifies that block pointers stay within physical disk boundaries, detects multiply-claimed blocks (where two files claim the same sector), and verifies extent tree structures.
• Pass 2: Checking Directory Structure
  Starting from the root directory (Inode 2), e2fsck traverses directory entries. It ensures filenames do not exceed 255 bytes, checks that directories point to valid inodes catalogued in Pass 1, and verifies that the first two entries in every directory are . (self) and .. (parent).
• Pass 3: Checking Directory Connectivity
  The utility confirms that every directory discovered in Pass 2 connects back to the global filesystem root. Any orphaned directories whose parents were destroyed are safely re-anchored into the /lost+found directory (allocated at Inode 11).
• Pass 4: Checking Reference Counts
  e2fsck compares the directory link count discovered during Pass 2 and 3 against the recorded i_links_count integer inside each inode. Discrepancies are adjusted to prevent disk space leaks upon deletion. Files with zero links but open reference counts are moved to /lost+found.
• Pass 5: Checking Group Summary Information
  The utility recalculates the on-disk Block Allocation Bitmaps and Inode Allocation Bitmaps from scratch, comparing memory calculations against on-disk tables. Any discrepancies in free block and inode counts are corrected and written to the block group descriptors.

The Fatal Hazard: Running fsck on Mounted Filesystems

Executing fsck on a filesystem mounted in read-write (rw) mode is one of the most catastrophic administrative mistakes in storage management.

When a filesystem is mounted read-write, the Linux kernel buffers disk changes in high-speed RAM caches, delaying writes to physical storage until kernel flush threads run. If fsck runs simultaneously, it reads stale block data from the physical drive, misinterprets in-flight kernel operations as corruption, and modifies the raw metadata. Seconds later, when the kernel flushes its memory cache, it overwrites fsck's changes with outdated pointers—causing irreversible data loss across the volume.

Core Flags & Quick Start Reference

The fsck command functions as a wrapper that automatically identifies the underlying filesystem type (via /etc/fstab or blkid) and delegates work to the correct driver (fsck.ext4, fsck.xfs, fsck.vfat).

Baseline Non-Destructive Health Audit

To evaluate an unmounted volume safely without altering a single bit, run a forced, non-destructive audit with a live progress indicator:

sudo fsck.ext4 -fnv -C 0 /dev/sdb1

e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
[========================================] 100.0%
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdb1: 14/1310720 files (0.0% non-contiguous), 126322/5242880 blocks

5 Production-Grade Real-World Use Cases

Use Case 1: Non-Interactive Automated Preen Repair & Bitmask Exit Code Triage in Recovery initramfs / CI Pipeline

Scenario

An automated cluster provisioning node experiences an ungraceful reboot during heavy disk I/O. The boot sequence halts in the early user-space initramfs environment because the root partition was unmounted dirty. You must deploy an automated script that attempts a safe "preen" repair, evaluates the binary bitmask exit code returned by fsck, and either proceeds with booting or halts for manual investigation.

#!/usr/bin/env bash
# Automated Filesystem Triage Engine for initramfs/Deployment Pipelines
set -o pipefail

TARGET_DEV="/dev/mapper/vg_system-lv_root"

echo "[i] Unmounting target if mounted read-only..."
umount "$TARGET_DEV" 2>/dev/null || true

echo "[i] Executing safe preen repair against $TARGET_DEV..."
fsck.ext4 -p -f "$TARGET_DEV"
EXIT_CODE=$?

echo "[i] fsck returned raw exit code: $EXIT_CODE"

# Bitmask Bit Evaluation based on fsck/e2fsck specification:
# 0    - No errors
# 1    - File system errors corrected
# 2    - System should be rebooted
# 4    - File system errors left uncorrected
# 8    - Operational error
# 16   - Usage or syntax error
# 32   - E2fsck canceled by user request
# 128  - Shared library error

if [ $EXIT_CODE -eq 0 ]; then
    echo "[+] SUCCESS: Filesystem is pristine. Proceeding with boot."
    exit 0
elif [ $((EXIT_CODE & 4)) -ne 0 ] || [ $((EXIT_CODE & 8)) -ne 0 ]; then
    echo "[!] CRITICAL ERROR: Uncorrected filesystem errors or operational fault detected ($EXIT_CODE)." >&2
    echo "[!] Halting automated sequence. Engaging remote rescue shell." >&2
    exit 1
elif [ $((EXIT_CODE & 2)) -ne 0 ] || [ $((EXIT_CODE & 1)) -ne 0 ]; then
    echo "[*] WARNING: Errors were corrected ($EXIT_CODE). Reboot/Remount required."
    sync
    exit 0
fi

Terminal Execution & Output

/bin/bash /opt/storage_triage.sh

[i] Unmounting target if mounted read-only...
[i] Executing safe preen repair against /dev/mapper/vg_system-lv_root...
/dev/mapper/vg_system-lv_root: Superblock last mount time is in the future.
    (by less than a day, probably due to the hardware clock being incorrectly set)
/dev/mapper/vg_system-lv_root: Replaying journal...
/dev/mapper/vg_system-lv_root: Inode 1310729 ref count is 2, should be 1.  FIXED.
/dev/mapper/vg_system-lv_root: Free blocks count wrong for group #40 (12431, counted 12435).
/dev/mapper/vg_system-lv_root: Free blocks count wrong (3451230, counted 3451234).
/dev/mapper/vg_system-lv_root: 524288/2621440 files (0.8% non-contiguous), 4521984/10485760 blocks
[i] fsck returned raw exit code: 1
[*] WARNING: Errors were corrected (1). Reboot/Remount required.

Output Analysis

1. Superblock last mount time is in the future: Detects a slight Real-Time Clock (RTC) drift, which preen mode safely updates.
2. Replaying journal: The JBD2 engine replayed uncommitted transactions from the dirty journal buffer.
3. Inode 1310729 ref count is 2, should be 1. FIXED.: Pass 4 discovered an unreferenced hardlink mismatch and adjusted the counter without data loss.
4. Free blocks count wrong...: Pass 5 detected allocation bitmap discrepancies from interrupted writes and corrected the free block count.
5. Exit code: 1: Evaluates to bitmask 1 (FS_ERRORS_CORRECTED), allowing the automated pipeline to proceed cleanly.

Administrator Next Steps

Verify the volume mounts properly with mount -o ro /dev/mapper/vg_system-lv_root /mnt and check /mnt/lost+found to confirm no configuration files were displaced during repair.

Use Case 2: Restoring from Alternate Superblocks After SAN Controller Reset Corrupts Block 0/1

Scenario

A Fibre Channel SAN volume hosting virtual machine images suffers corruption during a storage controller firmware update. The primary superblock at Block 0 is overwritten with null bytes, causing mount attempts to fail: mount: /mnt/data: wrong fs type, bad option, bad superblock on /dev/mapper/mpatha. You must locate the backup superblocks and repair the partition using fsck -b.

Step 1: Probe Device Architecture and Locate Superblock Offsets

Because the damaged filesystem cannot be read directly, use mke2fs with the non-destructive -n switch to reveal the exact block locations where backup superblocks were created during original formatting:

sudo mke2fs -n -b 4096 /dev/mapper/mpatha

mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 262144000 4k blocks and 65536000 inodes
Filesystem UUID: a7b8c9d0-1e2f-4a5b-8c9d-0e1f2a3b4c5d
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

Step 2: Execute Emergency Repair Pointing to Primary Alternate Superblock

sudo fsck.ext4 -b 32768 -y -v /dev/mapper/mpatha

Terminal Execution & Output

e2fsck 1.46.5 (30-Dec-2021)
/dev/mapper/mpatha was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Relocating group 0's block bitmap to 1025...
Relocating group 0's inode bitmap to 1026...
Relocating group 0's inode table to 1027...
Restarting e2fsck from the beginning...
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  +(1025--1026) +(1027--1539)
Fix? yes

Free blocks count wrong for group #0 (31742, counted 31228).
Fix? yes

/dev/mapper/mpatha: ***** FILE SYSTEM WAS MODIFIED *****
/dev/mapper/mpatha: 114209/65536000 files (1.2% non-contiguous), 89410294/262144000 blocks

Output Analysis

1. -b 32768: Bypassed the corrupt zeroed sector in Block Group 0 and restored filesystem state from the backup copy at Block 32768.
2. Relocating group 0's block bitmap/inode table: Reconstructed the critical metadata pointers for Block Group 0.
3. Block bitmap differences: Fixed: Realigned the primary block group allocation table with verified inode mappings.
4. FILE SYSTEM WAS MODIFIED: Confirms the primary superblock has been restored from the backup geometry.

Administrator Next Steps

Verify that the filesystem state has been updated to clean using tune2fs:

sudo tune2fs -l /dev/mapper/mpatha | grep -E "Filesystem state|Last checked|Block size"

Filesystem state:         clean
Last checked:             Tue Aug 18 09:12:44 2026
Block size:               4096

Use Case 3: Non-Destructive Dry-Run Auditing on Live Storage via LVM Snapshot Staging

Scenario

A PostgreSQL database server experiences elevated write latency, raising suspicion of filesystem corruption. Production uptime policies prohibit taking the multi-terabyte volume offline for an unverified issue. You must perform a complete 5-pass structural audit by creating an LVM point-in-time snapshot and running a dry-run e2fsck with undo tracking.

Step 1: Create a Consistent Point-in-Time LVM Snapshot

sudo lvcreate -L 50G -s -n lv_db_snap /dev/vg_database/lv_data

  Logical volume "lv_db_snap" created.

Step 2: Conduct Dry-Run e2fsck with Scratch Undo Log Generation

Execute a read-only audit against the snapshot, recording potential repairs to an undo file:

sudo e2fsck -nv -E undo_img=/var/log/fsck_snap_undo.img /dev/vg_database/lv_db_snap

Terminal Execution & Output

e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Inode 4194308 has illegal block(s).  Clear? no
Illegal block 98412032 (unsigned) in extent of inode 4194308.  CLEARED.
Inode 4194308, i_size is 104857600, should be 104853504.  Fix? no
Extent tree for inode 4194308 would be narrower by 1 level.  Fix? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(98412032--98412033)
Fix? no

Free blocks count wrong for group #3003 (14200, counted 14202).
Fix? no

/dev/vg_database/lv_db_snap: 4194304/67108864 files (4.2% non-contiguous), 198401928/268435456 blocks

Output Analysis

1. -n: Strict dry run. Every prompt is answered with no, ensuring zero changes are made to the snapshot or production volume.
2. Inode 4194308 has illegal block(s): Pinpoints corruption in Inode 4194308, which references block 98412032—outside valid group boundaries.
3. Extent tree for inode would be narrower: Detects an inflated extent tree node requiring rebalancing.
4. Block bitmap differences: Identifies two orphaned blocks that can be recovered during maintenance.

Administrator Next Steps

Identify which database table or index corresponds to Inode 4194308 using debugfs:

sudo debugfs -R "ncheck 4194308" /dev/vg_database/lv_db_snap

Once identified, schedule a short maintenance window to unmount the volume, execute e2fsck -p /dev/vg_database/lv_data, run a PostgreSQL REINDEX, and remove the temporary snapshot: sudo lvremove -y /dev/vg_database/lv_db_snap.

Use Case 4: Bad Sector Surface Sweeping & Inode Remapping on Degraded Block Media

Scenario

A spinning-disk SAS drive in a backup array produces kernel SCSI errors (Medium Error: Unrecovered read error), and SMART metrics indicate an increasing Current Pending Sector Count. You must run a non-destructive read-write surface sweep via fsck to prompt the drive firmware to remap damaged sectors and update the bad-block table without losing existing directory structures.

Command Invocation

Specifying -c twice (-c -c) executes an exhaustive, non-destructive read-write surface test: it reads each block, writes a test pattern, verifies the pattern, and restores the original data:

sudo fsck.ext4 -f -c -c -k -v /dev/sdc1

(The -k flag preserves existing entries in the bad-block inode).

Terminal Execution & Output

e2fsck 1.46.5 (30-Dec-2021)
/dev/sdc1 was not cleanly unmounted, check forced.
Checking for bad blocks in non-destructive read-write mode
From block 0 to 1953514583:
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: 12.45% done, 1:42:10 elapsed. (0/0/0 errors)
Testing with random pattern: done                                                 
Pass 1: Checking inodes, blocks, and sizes
Updating bad block inode with 3 newly discovered bad blocks:
    Block 245102914
    Block 245102915
    Block 891240102
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc1: 1849102/244190624 files (0.1% non-contiguous), 894120391/1953514584 blocks

Output Analysis

1. Checking for bad blocks (non-destructive read-write test): Tests every sector across multiple pattern passes.
2. Updating bad block inode with 3 newly discovered bad blocks: Inode 1 (the reserved bad-block table) records the three failed sectors, preventing future allocations to these physical locations.
3. FILE SYSTEM WAS MODIFIED: Disk firmware successfully triggered sector reallocation and updated the allocation bitmaps.

Administrator Next Steps

Inspect the bad-block allocation list to verify the recorded sectors:

sudo dumpe2fs -b /dev/sdc1

245102914
245102915
891240102

Arrange for a drive replacement; while fsck quarantined the bad sectors, hardware media errors tend to spread over time.

Use Case 5: Orphaned Inode Recovery & /lost+found Forensic Triage Following Sudden Power Loss

Scenario

A server suffers a dual power-supply failure during high-throughput logging. Following an emergency fsck -y run, the system boots, but several critical configuration files, SSL certificates, and scripts have been detached from the directory structure and placed into /lost+found as numeric inode names (e.g., #5241029). You must identify and restore these files using file signature and MIME-type analysis.

Step 1: Examine the Raw /lost+found Structural Debris

sudo ls -lah /mnt/data/lost+found | head -n 15

total 1.2G
drwx------  2 root root  16M Aug 18 09:30 .
drwxr-xr-x 24 root root 4.0K Aug 18 08:00 ..
-rw-r--r--  1 root root 4.2K Aug 18 09:30 #5241029
-rwxr-xr-x  1 root root  18M Aug 18 09:30 #5241030
-rw-r--r--  1 root root 1.2K Aug 18 09:30 #5241031
-rw-r--r--  1 root root  89M Aug 18 09:30 #5241032
-rw-------  1 root root 1.7K Aug 18 09:30 #5241033

Step 2: Deploy Automated Inode Classification and Forensic Recovery Script

#!/usr/bin/env bash
# Automated /lost+found Forensic Identification Engine
set -euo pipefail

LOST_DIR="/mnt/data/lost+found"
RESTORE_DIR="/mnt/data/restored_assets"

mkdir -p "$RESTORE_DIR"/{binaries,configs,keys,archives,unknown}

for file in "$LOST_DIR"/#*; do
    [ -e "$file" ] || continue

    FILENAME=$(basename "$file")
    MIME_TYPE=$(file -b --mime-type "$file")
    DESCRIPTION=$(file -b "$file")

    echo "Processing $FILENAME -> $DESCRIPTION ($MIME_TYPE)"

    case "$MIME_TYPE" in
        text/plain|text/x-shellscript|application/json|text/xml)
            if grep -q "BEGIN RSA PRIVATE KEY\|BEGIN OPENSSH PRIVATE KEY" "$file"; then
                mv "$file" "$RESTORE_DIR/keys/${FILENAME}.key"
            elif grep -q "server {" "$file" || grep -q "\[Unit\]" "$file"; then
                mv "$file" "$RESTORE_DIR/configs/${FILENAME}.conf"
            else
                mv "$file" "$RESTORE_DIR/configs/${FILENAME}.txt"
            fi
            ;;
        application/x-pie-executable|application/x-executable)
            mv "$file" "$RESTORE_DIR/binaries/${FILENAME}.bin"
            ;;
        application/zip|application/x-tar|application/gzip)
            mv "$file" "$RESTORE_DIR/archives/${FILENAME}.tar.gz"
            ;;
        *)
            mv "$file" "$RESTORE_DIR/unknown/${FILENAME}"
            ;;
    esac
done

echo "[+] Classification and triage completed successfully."

Terminal Execution & Output

sudo /bin/bash /opt/forensic_recovery.sh

Processing #5241029 -> OpenSSH RSA private key (text/plain)
Processing #5241030 -> ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV) (application/x-pie-executable)
Processing #5241031 -> JSON data (application/json)
Processing #5241032 -> gzip compressed data, from Unix, original size modulo 2^32 104857600 (application/gzip)
Processing #5241033 -> PEM certificate (text/plain)
[+] Classification and triage completed successfully.

Output Analysis

1. OpenSSH RSA private key: Extracted a crucial SSH deployment key from Inode #5241029.
2. ELF 64-bit LSB pie executable: Isolated an application daemon binary for hash comparison against known releases.
3. JSON data: Recovered an application configuration file, ready to be restored to /etc/app/config.json.

Administrator Next Steps

Verify recovered configurations against version control repositories, commit valid files, and optimise the enlarged /lost+found directory structure using e2fsck -f -D /dev/sdb1.

What Can Go Wrong: Architectural Anti-Patterns & Catastrophic Traps

1. The Blind -y Execution on Failing Physical Hardware

Running fsck -y or e2fsck -y against a drive experiencing active hardware failure (such as head-crashes or failing SSD controllers) can result in total data destruction.

When a failing disk returns I/O read errors (EIO), fsck assumes the unreadable sectors indicate corrupted metadata and removes every inode, directory reference, and extent pointer associated with those blocks. Within minutes, a drive that was mostly intact can have its entire file hierarchy wiped clean.

2. Filesystem Driver Confusion & Wrapper Mismatch

The generic /sbin/fsck wrapper detects filesystem types by inspecting disk signatures. If partition headers are heavily damaged, the wrapper might invoke the wrong driver (for example, attempting to parse an XFS partition with fsck.ext4).

Enterprise Best Practices: Defensive Storage Operations

Graceful Pre-Flight Unmount Validation

Never assume a mount point is idle based on memory. Use fuser and lsof to inspect and close active file handles before attempting to unmount:

# 1. Inspect active processes using the mount point:
sudo fuser -vm /mnt/data

# 2. Terminate lingering processes gracefully:
sudo fuser -k -15 -m /mnt/data

# 3. Unmount the volume safely:
sudo umount -v /mnt/data

Proactive Filesystem Check Schedules

Many modern distributions disable routine mount-count checks by default, relying entirely on journals. In enterprise systems, you can configure defensive periodic checks with tune2fs to force validation after a set number of mounts or elapsed days:

# Configure forced check every 30 mounts or 90 days, with 5% reserved block threshold:
sudo tune2fs -c 30 -i 90d -m 5 /dev/mapper/vg_system-lv_data

Authoritative Documentation & Further Reading

To learn more about storage internals and filesystem recovery, consult these references:

• fsck(8) — Linux System Administration Manual
• e2fsck(8) — Ext2/Ext3/Ext4 File System Checker Specification
• Linux Kernel Ext4 Filesystem Architecture and Data Structures Documentation
• ArchWiki Comprehensive Guide to Filesystem Maintenance and Recovery
• tune2fs(8) — Adjust Tunable File System Parameters Manual
• badblocks(8) — Search a Device for Bad Blocks Manual

Today's Takeaway

The difference between a manageable storage incident and a catastrophic outage comes down to knowing when not to press y. Right now, take five minutes on your own machine to run a completely safe, read-only diagnostic on an unmounted partition or LVM snapshot using sudo fsck.ext4 -fnv /dev/<your-device>. Watch the five validation passes progress, observe how your system maps inodes and block groups, and verify that your recovery procedures are solid long before the next emergency alert wakes you up in the middle of the night.