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/ _______________________________________________ Ext3-users@redhat.com https://listman.redhat.com/mailman/listinfo/ext3-users
