mke2fs

Denys Vlasenko vda.linux at googlemail.com
Tue Oct 20 16:04:24 UTC 2009


On Tue, Oct 20, 2009 at 5:20 PM, Vladimir Dronnikov <dronnikov at gmail.com> 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


More information about the busybox mailing list