Ext3 users - Apr 2003 - Odd error: Physical size does not match superblock size

Hello, I had something interesting happen on a RH8 ext3 system I setup.I
am at a loss to understand what happened.

Info:
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)

Problem:
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.

I tried fsck and e2fsck passes with varied options on /dev/hda3
(/first1) to hopefully fix the problem (it did not). fsck would complain
upon starting that the drive had errors, but never found any and
completed successfully without reporting the errors.
I could then run fsck again, and the error message would repeat, but
nothing would actually be found during the fsck passes.

I also did a badblocks check. (nothing)

I tried several more things. No matter what I tried, I could not fix
this problem. Anybody have a clue as to what I could have done?

Solution I chose:
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.

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?

Thanks,
-- 

Bobbyjoe Glover <glover@pa.msu.edu>

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
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/