Bug 204104 - mkfs.ext3 is really slow when /etc/mke2fs.conf is missing
mkfs.ext3 is really slow when /etc/mke2fs.conf is missing
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-08-25 11:59 EDT by Nate Straz
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version: 1.40.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-20 14:16:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nate Straz 2006-08-25 11:59:10 EDT
+++ This bug was initially created as a clone of Bug #201645 +++

Description of problem:

mkfs.ext3 runs about 10x slower during a RHEL5 install as it did when
doing a RHEL4 install.

-- Additional comment from pjones@redhat.com on 2006-08-21 10:55 EST --
This is mke2fs.conf not being in the installer root.  Fixed in rawhide.

-- Additional comment from nstraz@redhat.com on 2006-08-25 11:21 EST --
So a missing config file cripples mke2fs?

I tried a simple experiment on this volume:

  LV             VG            Attr   LSize   Origin Snap%  Move Log Copy% 
  morph-cluster0 morph-cluster -wi-a- 915.70G                              

[root@morph-01 etc]# /usr/bin/time mke2fs -q -j /dev/morph-cluster/morph-cluster0 
0.77user 62.97system 2:35.24elapsed 41%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+11383minor)pagefaults 0swaps
[root@morph-01 etc]# mv /etc/mke2fs.conf /etc/should-be-mke2fs.conf
[root@morph-01 etc]# /usr/bin/time mke2fs -q -j /dev/morph-cluster/morph-cluster0 
3.42user 91.23system 56:22.95elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+34200minor)pagefaults 0swaps

So on a nearly 1TB volume, mkfs time changed from 2:35.24 to 56:22.95. Ouch!
Comment 1 Nate Straz 2006-08-25 12:10:36 EDT
Here's the difference in the file system made, with and without a mke2fs.conf.


tune2fs w/o mke2fs.conf

Filesystem features:      has_journal filetype sparse_super
Block count:              960180224
First block:              1
Block size:               1024
Fragment size:            1024
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         1024
Inode blocks per group:   128

tune2fs w/ mke2fs.conf

Filesystem features:      has_journal resize_inode dir_index filetype
sparse_super large_file
Block count:              240045056
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Comment 2 Eric Sandeen 2007-05-05 00:22:49 EDT
At a minimum should probably make the built-in defaults match the defaults in
the *stock* upstream mke2fs.conf file, if they don't already.
Comment 3 Eric Sandeen 2007-05-05 00:38:41 EDT
... and they don't match.

Stock upstream conf file says 4k blocks, while the code itself defaults to 1k.

Options differ too; conf says "sparse_super,filetype,resize_inode,dir_index"
while code says "filetype,sparse_super"

I'll try to get this fixed upstream.

Comment 4 Eric Sandeen 2007-05-07 13:30:51 EDT
I sent a patch upstream to make the mke2fs.c defaults match the mke2fs.conf

Comment 5 Eric Sandeen 2007-05-08 11:01:21 EDT
The change has been committed upstream:

Comment 6 Eric Sandeen 2007-09-20 14:16:58 EDT
Nate has given me permission to just punt this to fedora, I don't think it's an
issue that's going to hit RHEL.  This fix should be in 1.40.2 in both F7 and F8.

Note You need to log in before you can comment on or make changes to this bug.