e2fsck complains that either super block or partition table is corrupt, why ?

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 3
  • Red Hat Enterprise Linux 4
  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7

Issue

  • While doing a file system check using 'e2fsck', it complains as follows :
bash-3.2# e2fsck /dev/mapper/vg_name-lv_name
e2fsck 1.39 (29-May-2006)
The filesystem size (according to the superblock) is 66584576 blocks
The physical size of the device is 65798144 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

  • The size of the file system does not match the size of the device.

  • e2fsck fails to read block numbers after the specific size and aborts.

Pass 1: Checking inodes, blocks, and sizes
Error reading block <block-number> (Invalid argument) while getting next inode from scan. Ignore error? no

Error while scanning inodes <inode-number>: Can't read next inode
e2fsck: aborted

Resolution

  • Check the current size of the file system and the device size.

  • Resize the file system size to the size of the actual device size.

# umount <file-system>

# resize2fs <device-name>

NOTE: Ensure that a valid file system backup is available as a file system corruption might have already happened or resize2fs might cause file system corruption

Root Cause

  • An improper or incomplete file system or device resizing can leave the file system superblock corrupted. If the superblock is not updated with the current size of the file system, it would report a wrong size of the file system whereas the actual device is different.

  • Or in some cases, it has been observed that the partition table is corrupt. The problem in such cases are since a file system does not keep any backups for a partition table like a superblock backup, it is very hard to restore the partition to the previous state.

  • It can be restored if the exact cylinder/sector geometry of the previous/existing partition is known. The trick is to do a partition using parted or fdisk maintaining the same cylinder limits. But that is in most cases not possible. In such a situation, mount the partition and do a data backup as soon as possible. After this, repartition the device if possible and copy over the data.

Diagnostic Steps

  • Identify the current file system size
# dumpe2fs <file-system> |grep "Block count"
  • Check the size of the underlying device.
# lvs -ao +devices
  • Check if there was any resizing of file system or the device was done before the issue occurred.
The filesystem size (according to the superblock) is 126220288 blocks
The physical size of the device is 124909568 blocks

The filesystem size:
126220288 * 4096 = 481.49 GB

The physical size:
124909568 * 4096 = 476.49 GB

The PV is 5GB short, or the filesystem is 5GB too large.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments