On Thu, 3 Apr 2008 23:24:43 -0400 Theodore Tso <tytso@xxxxxxx> wrote: > On Thu, Apr 03, 2008 at 09:28:58AM -0500, Jose R. Santos wrote: > > I blame Undo Manager for being so slow that cause me to skip some of > > the testing needed to be done. > > If that means we need a patch to disable the undo manager, via a > command-line option, feel free. :-) Im sufficiently annoyed that I may just do that. > > I was incorrectly checking the feature > > flag instead of checking the value of fs->super->s_log_groups_per_flex. > > Actually, you should check both, and we need to make mke2fs have an > intelligent default, which can be overridden via mke2fs.conf. Yes it should check both(will fix). I was expecting more people to give flexbg a test before trying to determined an intelligent default though. > Also, it looks like this patch doesn't create a valid filesystem in > combination with meta_bg: > > mke2fs G 32 -O meta_bg,flex_bg,uninit_groups,^resize_inode /tmp/foo.img > > Then try running "e2fsck -f /tmp/foo.img" with the patch applied. Wow, it really breaks. Throws e2fsck into an infinite loop. > One obvious question is why is this patch so fragile....? Is there > some way we can make it more likely not to break given other changes > to e2fsprogs in the future. Getting the right free block count for every group descriptor seems to be the tricky part since libe2fs make all sort of assumptions about number of used blocks that break when meta-data is no longer on the same block group. Seems like I forgot a check for the adjusted flexbg block group size in meta_bg since the first place it barfs is in group 127 which is the last group of the meta_bg with a group descriptor block being used. This should be easy to find and fix. > - Ted -JRS -- 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
