Date: Fri, 23 Nov 2001 17:04:34 +0200 From: Sheldon Hearn <sheldonh@starjuice.net> To: freebsd-arch@FreeBSD.org Subject: Using a larger block size on large filesystems Message-ID: <45421.1006527874@axl.seasidesoftware.co.za>
next in thread | raw e-mail | index | archive | help
Hi folks,
Background:
I recently got some disk space to play with and, following discussions
hear about ffs block sizes, I used postmark [1] to test the
"MTA-visible" difference between an 8192/1024 vs a 16384/2048
filesystem.
I found that, for this large filesystem, the mixed MTA-like transaction
rate [2] on a 16384/2048 ffs [3] filesystem outperforms the 8192/1024
ffs filesystem by a factor of 67% (using 2-4 hours benchmarks that
consistently show exactly the same transaction rate when repeated).
Compared with the 1% improvement I score with noatime and the 38%
improvement scored by using a Mylex controller with 15Krpm drives
instead of a Compaq SmartArray (yuk! yuk!) controller with 10Krpm
drives, this is a valuable optimization!
The question:
I'm now looking at finding the minimum filesystem size for which
defaulting the block/frag ratio to 16384/2048 would make sense.
I know there was some discussion on -arch recently about teaching
sysinstall to make this decision. However, I'd like to suggest that
newfs do the thinking instead.
Obviously, if either of the -b or -f options are specified, the current
behaviour will be unchanged. However, I'd like to code in a filesystem
size threshold over which newfs sans -b or -f options will jump up to
block/frag sizes of 16384/2048.
And more obviously, I'm going to do a lot more testing to see what kinds
of applications might be negatively impacted by the change!
Assuming that the threshold my research leads me to is agreeable to the
community, is there any sense in making this a sysinstall decision, or
can I press on with making it a newfs job?
Ciao,
Sheldon.
[1] See the ports/bechmarks/postmark/pkg-descr for information on
postmark, a storage benchmark with MTAs and news servers in mind.
[2] Postmark v1.5 configuration: 100000 files, 500000 transactions,
10KB to 25KB file size spread, random seed 42.
[3] Soft updates enabled in both cases.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45421.1006527874>