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