Bug 184064 - EXT3 needs a block size drop down for 1K, 4K, or 8K
EXT3 needs a block size drop down for 1K, 4K, or 8K
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-05 15:36 EST by Darwin H. Webb
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-06 21:54:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Darwin H. Webb 2006-03-05 15:36:39 EST
Description of problem:
EXT3 defaults to 1K block size, no way to override during install.
Modren disk perfoemace is degraded with 1K block size. Best fit is 4K.
A resiers 3.6 fs (using large blocks) on a 40 GB 2 MB buffer no fbuffer flush
performs 3 times faster than EXT3 with 1K block.
This is for FC rpm based, debian based, and slackware based. I have ran all 3
types on this disk and the OS or apps make no difference due to the 1K blocks
vs. large blocks as far as overall performace in boot time, update time,
indexing time. etc.

Please add block size selection for fs's especially EXT3 to anaconda and LVM gui
tool.
 
Version-Release number of selected component (if applicable):
current ( any)

How reproducible:
always

Steps to Reproduce:
1.Install FC and the default block size is 1K
2.
3.
  
Actual results:
1K block size - slow (and I mean really slow) disk perforance. 7-9 MB /s

Expected results:
A dropdown to select block size to create 80-90 per cent of disk speend limit.
18-22 MB / s for Udma33 channel. 

Additional info:
There is no practical or logical reason for small blocks anymore on modern disk
drives. When space was a premium and disks were small it may have been but is no
long trure. In fact it is a throtttle on the whole system's speed.
Waste fact is mere MB's.
Comment 1 Jeremy Katz 2006-03-06 15:43:50 EST
Forcing this decision on the user is the wrong idea -- mke2fs should just do the
right thing
Comment 2 Stephen Tweedie 2006-03-06 16:06:03 EST
Here's my root filesystem from an install I completed from rawhide earlier today
(into a Xen guest):

# tune2fs -l /dev/VolGroup00/LogVol00 |grep Block\ size
Block size:               4096

So it _is_ creating 4k blocksize filesystems.

mke2fs does fall back to a smaller blocksize if the filesystem itself is small
enough, because for very small filesystems, the 4k blocksize results in
excessive wasted space.  

How large a disk were you formatting to get 1k blocksize by default?
Comment 3 Darwin H. Webb 2006-03-06 21:28:46 EST
I humbely stand corrected. The block size is 4096.
I guess I entrupted the man as default is 1024. The means to me that is what it
will be if not specified.

In trying to make a set of lvm lv to test a second install by using the FC5 lvm
gui tool to create the pv/vg and lv, then manually mk2fs.ext3 -b 4096 on the lv.

It allowed me to do this and the format of ext3 was good. However it did it over
a reiserfs partition type without a complaint.
Therefore on the install the anaconda would have nothing to do with the lv and
it could not be mounted.

So block size is ok. man page could be more clear.
lvm gui needs to check partition type before allowing pv or at least formatting
with different fs.

OK, time for some green eggs and crow pizza. :)

Darwin
Comment 4 Stephen Tweedie 2006-03-06 21:54:27 EST
OK, thanks for following up!

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