On Tue 12-06-18 13:04:00, Andreas Dilger wrote: > On Jun 12, 2018, at 3:53 AM, Jan Kara <jack@xxxxxxx> wrote: > > > > When s_inodes_count would overflow given number of groups and inodes per > > group, we cannot currently fix the breakage in e2fsck as that requires > > trimming number of groups or inodes per group which both means data & > > inode migration etc. Just trimming sb->s_inodes_count is not enough as > > kernel's inode allocation code is not able to handle filesystems where > > not all inodes in the last group are usable. So don't pretend we can fix > > s_inodes_count overflow by just trimming the s_inodes_count value. > > > > When s_inodes_count is just wrong but will not overflow, let's fix it. > > Also move this check before we use s_inodes_count for checking > > s_first_ino. > > > > Signed-off-by: Jan Kara <jack@xxxxxxx> > > I guess that still leaves an open issue of what a user can do if the > superblock (correctly or incorrectly) has groups * inodes_per_group > that overflows 2^32, since it seems e2fsck would abort in that case. Yes, e2fsck would abort as in the case of other non-trivial superblock corruptions. My thinking was that in that case user can use debugfs (hence my following debugfs changes) to fix the filesystem. > I'd think that one option would be to reduce the group count until > the number of inodes < 2^32, which might lose some files at the end > of the filesystem, but more likely would not lose anything since the > kernel would have written those inodes into the wrong place anyway. > > The existing code takes the approach of truncating the last group, > which at least makes the filesystem usable again, though it risks > corrupting inode #1 (EXT2_BAD_INO) on older kernels should the last > inode be allocated. That probably isn't a huge danger in the end. Actually currently e2fsck never succeeded in even opening the filesystem with corrupted s_inodes_count so it could not fix anything. So my change is at least an improvement that it reports what's wrong and fixes the "easily fixable" corruptions. Reducing number of block groups is doable (although libext2fs code is not quite prepared for that so it may need some fixups). I was just a bit worried that if the s_inodes_count corruption is not due to resize2fs bug, reducing the group count may actually be a wrong thing to do and could cause serious damage to the filesystem. What do people think? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
