Fixing Filesystem Superblock Corruption in Linux

Common Cause: Power loss or unexpected shutdown

Most times superblock corruption happens when the power cuts while the drive is writing. The superblock — that's the first 1024 bytes of the partition — gets scrambled. When you try to mount it, you get something like:

mount: /data: can't read superblock on /dev/sdb1.

Or you might see Invalid argument or Structure needs cleaning. Don't panic. The real fix is using a backup superblock.

Step 1: Check the filesystem type

First, find out what filesystem you're dealing with. Run:

sudo blkid /dev/sdb1

You should see something like TYPE="ext4". If it's ext2 or ext3, same steps work. If it's XFS or Btrfs, stop here — they handle corruption differently.

Step 2: Find backup superblock locations

For ext4 filesystems, backup superblocks are at fixed positions. Run this command:

sudo mke2fs -n /dev/sdb1

Important: The -n flag means "dry run." It won't actually create a filesystem. It just prints what it would do. Look for lines that say:

Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, ...

Write down those numbers. You'll need them.

Step 3: Run fsck using a backup superblock

Now use the first backup superblock to check and repair the filesystem. Start with the first number (usually 32768):

sudo fsck -b 32768 /dev/sdb1

After you run this, you'll see something like:

fsck from util-linux 2.36.1
e2fsck 1.46.5 (30-Dec-2021)
/dev/sdb1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
...
Pass 5: Checking group summary information
/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

If it says "FILE SYSTEM WAS MODIFIED" that's good — it fixed things. Then try mounting again:

sudo mount /dev/sdb1 /data

If that works, you're done. If not, repeat with the next backup superblock (98304, then 163840, etc.) until one works.

My take: 99% of the time the first or second backup superblock does the trick. Don't waste time trying all 15 numbers unless you have to.

Second cause: Filesystem driver mismatch

Sometimes the superblock isn't corrupted — the kernel just can't read it because the wrong driver loaded. This happens when you upgrade the kernel and the new version doesn't have the right module. Or you're using an old ext4 filesystem with a newer kernel that expects a different version.

You'll see an error like:

mount: /data: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.

Step 1: Force the filesystem type

Try mounting with the explicit type:

sudo mount -t ext4 /dev/sdb1 /data

If that doesn't work, try ext3 or ext2:

sudo mount -t ext3 /dev/sdb1 /data

Sometimes the filesystem got created as ext3 but the superblock says ext4. The kernel might reject it. Forcing the type bypasses that check.

Step 2: Check for incompatible features

If forcing the type still fails, check what features the filesystem has:

sudo tune2fs -l /dev/sdb1 | grep -i feature

You'll see something like:

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize

If you see 64bit or metadata_csum your kernel might not support them. Check your kernel version:

uname -r

For 64bit features you need kernel 3.2 or newer. For metadata_csum you need 4.4 or newer. If your kernel is older, you can't mount it without disabling those features — which means you need to copy data to another drive and create a new filesystem.

Third cause: Bad blocks on the drive

Sometimes the superblock sits on a physical bad sector. No backup superblock will help because the drive hardware is failing. You'll know this is the case when:

• fsck with every backup superblock fails with the same error
• You see Input/output error in dmesg
• The drive makes clicking or grinding noises

Step 1: Check the SMART status

Run:

sudo smartctl -a /dev/sdb

Look at these numbers:

• Reallocated_Sector_Ct — if it's above 10, the drive is dying
• Current_Pending_Sector — if it's not zero, you have bad sectors
• Raw_Read_Error_Rate — if it's increasing, the drive is failing

Step 2: Try a read-only scan

If the drive is still responding but has bad blocks, you can try to force mount it read-only and copy your data off:

sudo mount -o ro,noload /dev/sdb1 /data

The noload option skips the journal replay. If it mounts, copy everything to a new drive immediately. This drive won't last.

Step 3: Use ddrescue for last resort

If the drive won't mount at all, use ddrescue to make a disk image on another healthy drive:

sudo ddrescue /dev/sdb /dev/sdc rescued.log

Replace /dev/sdc with a blank drive of equal or larger size. Then run fsck on the copy:

sudo fsck -b 32768 /dev/sdc1

My opinion: If you get to this point, the drive is toast. Don't trust it again. Replace it.

Quick Reference: Superblock Repair by Filesystem Type

One more thing: Always unplug the drive after the repair, count to 10, and plug it back in. Sounds dumb, but sometimes the kernel holds old superblock data in cache and fails the mount even after a successful repair. A full power cycle clears that cache.

If none of these fixes work, the filesystem is beyond repair. You'll need to format the drive and restore from backup. That's why backups matter — no one cares about superblocks when they have a good backup.