On Tue, Jul 21, 2009 at 12:21 PM, Andreas Dilger<adilger@xxxxxxx> wrote: >> I shouldn't need e2fsprogs to be compiled 64-bit as well, right? >> Currently I've got a 64-bit kernel with 32-bit userspace. > > Yes, that is a potential problem. It looks like it certainly is a problem with current e2fsprogs "pu" branch. My latest findings from basic testing (just mkfs.ext4, then e2fsck -fy, and -- if e2fsck modified the filesystem -- another e2fsck -fy) are as follows: 1) 64-bit mke2fs + 64-bit e2fsck Appears to work fine. No errors reported anywhere. 2) 64-bit mke2fs + 32-bit e2fsck Also appears to work fine. llverfs --partial looked okay, and e2fsck reported no errors. 3) 32-bit mke2fs + 64-bit e2fsck Mkfs.ext4 must have done something wrong, but e2fsck was able to fix it up, and future e2fsck (32 or 64-bit) runs reported no issues. e2fsck output was: Block bitmap differences: +(1063780365--1063780367) +(1063780381--1063780383) +(1063782048--1063782431) -(5359140864--5359173631) Running mkfs through valgrind doesn't show any obvious errors. 4) 32-bit mke2fs + 32-bit e2fsck Same as (3), for the mkfs and the first e2fsck again reported fixing the same block bitmap differences. But after the first e2fsck was complete, the second e2fsck run reported: e2fsck: Superblock invalid, trying backup blocks... Group descriptor 0 checksum is invalid. Fix? yes Group descriptor 1 checksum is invalid. Fix? yes ... Group descriptor 81774 checksum is invalid. Fix? yes followed by tons of block bitmap differences. -Justin -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
