Can you send the full output of dumpe2fs -h? I suspect what happens
is that you might be testing a revision 0 file system.
>From e2fsprogs/lib/e2p/ls.c:
fprintf(f, "Filesystem revision #: %d", sb->s_rev_level);
if (sb->s_rev_level == EXT2_GOOD_OLD_REV) {
fprintf(f, " (original)\n");
#ifdef EXT2_DYNAMIC_REV
} else if (sb->s_rev_level == EXT2_DYNAMIC_REV) {
fprintf(f, " (dynamic)\n");
#endif
} else
fprintf(f, " (unknown)\n");
...
if (sb->s_rev_level >= EXT2_DYNAMIC_REV) {
fprintf(f, "First inode: %d\n", sb->s_first_ino);
fprintf(f, "Inode size: %d\n", sb->s_inode_size);
If you have a revision 0 file system, the fields s_first_ino and
s_inode_size are not defined, and so the inode size should always be
128. I did notice a bug where tune2fs -I 256 will try to do its thing
on a revision 0 file system, resulting in horrendous file system
corruption (the kernel will refuse to mount the file system, and
e2fsck will get terribly confused and try to "fix" it assuming an
inode size of 128, even though tune2fs -I tried to rewrite the rest of
the metadata blocks assuming an inode size of 256. Oops; this could
lead to data loss if there were actual real-world file systems still
using rev 0 file systems. I should still fix it...)
The thing is, a revision 0 file system has been obsolete for over a
decade, dating before ext4, and I'm pretty sure before ext3 was forked
off from ext2.
So I'm not sure how you could have generated such a file system. I do
know there were some dodgy mke2fs-like programs written by
organizations which were allergic to the GPL, but I doubt you would
have been using them if you were testing on Debian systems.
- Ted
