Hi,
On Wed 23-05-18 16:46:25, Jaco Kroon wrote:
> So I tracked down the fsck issue ... with a bit of additional debug
> output in the lib/ext2fs/openfs.c file, the if statement that is failing
> is this one:
>
> if (fs->group_desc_count * EXT2_INODES_PER_GROUP(fs->super) !=
> fs->super->s_inodes_count) {
> fprintf(stderr, "\ngroup to inodes problem ...
> group_desc_count=%u, inodes/group=%u, inode_count=%u\n\n",
> fs->group_desc_count, EXT2_INODES_PER_GROUP(fs->super),
> fs->super->s_inodes_count);
> retval = EXT2_ET_CORRUPT_SUPERBLOCK;
> goto cleanup;
> }
>
> And this gives us:
>
> group to inodes problem ... group_desc_count=524288, inodes/group=8192,
> inode_count=4294967295
>
> 524288 * 8192 = 4294967296
>
> As a result, and value other than 0 in the inode_count file will result
> in fsck refusing to fsck the filesystem, however, mounting with that bit
> of corruption does in fact work, so whilst fsck will not function at the
> moment at least the filesystem is mounted, but this will need to be
> sorted out somehow.
>
> I suspect this boils down to two things:
>
> 1. The kernel (as well as offline resize) needs to prevent resizes
> pushing inode count >= 2^32 (or if it hits exactly that just limit to
> 2^32-1).
So kernel resize had an off-by-one bug that it allowed to grow your fs to
64TB - it should have stopped you at 64TB - 128MB (one group less). Sent a
fix. Offline resize actually has the check correct.
> 2. fsck needs to be made aware of this.
Yeah, I guess I'll make lib/ext2fs/openfs.c accept also inode count of
MAX_INT...
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
