>> >> Against current git. Please, consider applying. > > Sorry... I pushed some fixes to git... > can you rediff? >
Sure. In a couple of minutes. > In current git, mkfs_ext2_test.sh shows that we are ok > in the whole 60k...8377k range, [8378..8410] is bad, > and I did not find yet the next "bad" value, but at least > up to 21000k mkfs_ext2_test.sh did not catch differences > so far. > > [8378..8410] range is when we start to get 2ns block group: > > > Apparently we are not trimming it as aggressively > as standard mke2fs. > > This does not happen at 16M, so it's not a wrong > cutoff constant (50), it's a buglet related to having > a backup superblock in group 1. > My point is that we hardly===never achieve consistence unless BB mke2fs reserve group descriptors! And "standard" "/lost+found" occupies more than 1 block. To check this while I'm rediffing, please try to define ENABLE_FEATURE_..._RESERVED as 1 and append "-n" to both mke2fs options. The resulting image will not be fsckable (that is because I haven't yet decrypted the relevant mke2fs logic), but the "numbers" printed by mke2fses should correlate much better. > > Can you confirm my mkfs_ext2_test.sh results? > Argh, I'm now developing in VirtualBox hosted on Windows :(. It would be painful to wait for big images. -- Vladimir _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
