[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Odd error: Physical size does not match superblock size

On Apr 17, 2003  14:12 -0400, Bobbyjoe Glover wrote:
> This system has two IDE disks, partitioned identically, and the largest
> partition on each (/dev/hda3 and /dev/hdb3, 96GB each) was mirrored in a
> linux software RAID-1 configuration.
> It was running fine for many months. Then I updated the kernel and
> needed to reboot accordingly. (2.4.18-14.8.0smp -> 2.4.18-27.8.0smp)

Possibly more than 6 months with only a handful of reboots?  If so, then
the reboot was the first time you actually ran e2fsck on it.

> Upon a reboot, fsck complained that /first1 (/dev/hda3)'s superblock or
> partition table reported 25712032 blocks, while the physical disk
> reported 25712016. (a difference of 16). I tested with new and old
> kernel, and the error occured on both.

The 16 blocks are the size of the MD RAID superblock (64kB)...

> Since I had the data backed up, I eventually formatted /dev/hda3 and put
> a new, clean ext3 fs on it. I then ran resize2fs and decreased the
> filesystem by 16 to match what the physical said. Then I rebuilt the
> RAID-1 array and the problem went away.

The problem is that you are creating the filesystem on /dev/hda3 and not
/dev/md0 (which is smaller by those 16 blocks because of the RAID superblock
at the end).

> I was hoping there would be a more elegant solution. Anybody have an
> idea how this error occured, or what I could have done differently?

Proper fix (if you have gotten yourseld into this problem already) is
to just use resize2fs to shrink the filesystem on /dev/md0 by 16 blocks.
Chances are that nothing is using those blocks anyways, so you are safe
(and if yes, then e2fsck will complain and fix it).

Cheers, Andreas
Andreas Dilger

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]