# mkfs.ext3 -F -b 1024 /dev/sdb1 2046000000 # mount /dev/sdb1 /uss_a mount: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so # dmesg | tail -n 2 EXT3-fs error (device sdb1): ext3_check_descriptors: Inode table for group 0 not in group (block 8065)! EXT3-fs: group descriptors corrupted! ... fsck doesn't like it either ... # fsck.ext3 /dev/sdb1 e2fsck 1.39 (29-May-2006) Group descriptors look bad... trying backup blocks... /dev/sdb1 was not cleanly unmounted, check forced.
Simpler test: mke2fs -j -F -b 4096 -m 0 -N 5217280 /mnt/test/fsfile2 327680 it's an off by one in calculating whether the inode table is within the block group; this only triggers for odd geometries when the inode table lands on the last block of the first group) Index: e2fsprogs-1.40.2/lib/ext2fs/check_desc.c =================================================================== --- e2fsprogs-1.40.2.orig/lib/ext2fs/check_desc.c +++ e2fsprogs-1.40.2/lib/ext2fs/check_desc.c @@ -61,7 +61,7 @@ errcode_t ext2fs_check_desc(ext2_filsys */ if (fs->group_desc[i].bg_inode_table < first_block || ((fs->group_desc[i].bg_inode_table + - fs->inode_blocks_per_group) > last_block)) + fs->inode_blocks_per_group - 1) > last_block)) return EXT2_ET_GDESC_BAD_INODE_TABLE; } return 0; without this it thinks it's corrupt, and also doesn't fix it (e2fsck finds an "error" each time it's run) Same fix needs to go into the kernel, in ext3_check_descriptors() Probably not a very high priority, although it's not *too* hard to hit; simply making a ~2T (though actually less...) 1k-block filesystem will trigger it.
and an even smaller fs useful for the regression test: mkfs.ext2 -F -b 1024 -m 0 -g 256 -N 3744 fsfile 1024
patch sent upstream
Ted, putting you on cc: in case you want to reference the RH bug nr.
e2fsprogs patch is upstream, http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=commitdiff;h=bd828a27e2cfec9f14837d9a693e2a414f44bf91 (Note to self, might want another bug for the same issue on the kernel side.)
moving to fedora as product; yes, this exists on rhel too but it's a bit obscure and has never been reported...
Going to just close this one as NEXTRELEASE; next upstream e2fsprogs will havve this fix. I don't think it's critical to pull it to fedora for now.