On Tue, Oct 20, 2009 at 5:20 PM, Vladimir Dronnikov <[email protected]> wrote: > * some clarifications in comments > * consistent "/lost+found" > > Against current git. Please, consider applying.
Sorry... I pushed some fixes to git... can you rediff? 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: Testing 8374 Testing 8375 Testing 8376 Testing 8377 Testing 8378 --- image_bb.out 2009-10-20 17:58:00.515296542 +0200 +++ image_std.out 2009-10-20 17:58:00.491297146 +0200 @@ -1,12 +1,11 @@ +warning: 185 blocks unused Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) -2096 inodes, 8378 blocks +2096 inodes, 8193 blocks 418 blocks reserved for the super user First data block=1 -2 block groups +1 block groups 8192 blocks per group, 8192 fragments per group -1048 inodes per group -Superblock backups stored on blocks: - 8193 +2096 inodes per 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. Can you confirm my mkfs_ext2_test.sh results? -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
