All of lore.kernel.org
 help / color / mirror / Atom feed
* best reiserfs mount options for generic benchmarking
@ 2002-09-14 11:09 rwhron
  0 siblings, 0 replies; 6+ messages in thread
From: rwhron @ 2002-09-14 11:09 UTC (permalink / raw)
  To: reiserfs-list

I want to use a consistent set of "best" mount options
for various i/o benchmarks on reiserfs.  (bonnie++,
tiobench, dbench).

I've been using "noatime", and was thinking of adding
"notail".  tail packing helps on the bonnie++ "lots
of small files" test, but for most cases, "notail"
may be better.

alloc=preallocmin=4:preallocsize=9 was needed in 
2.4.20-pre2 to eliminate a tiobench regression when
thread count is high.  Is that needed in 2.4.20-pre7
and 2.5.34 and beyond?

Also, mke2fs has an option to create a larger journal.
For ext3, I create a 400MB journal.  (one of the tests
creates 256 (12888 / 256) MB files).  Is a non-default
journal size available/desireable for reiserfs?

Any other recommendations?

-- 
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html


^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: best reiserfs mount options for generic benchmarking
@ 2002-09-14 16:47 rwhron
  2002-09-16  4:28 ` Valdis.Kletnieks
  0 siblings, 1 reply; 6+ messages in thread
From: rwhron @ 2002-09-14 16:47 UTC (permalink / raw)
  To: russell; +Cc: reiserfs-list

> Why?

Mainly for the reiserfs developers benefit.  Hans expressed some
interest in the numbers.  Also, if the tests take less time,
I can run more of them. :)

I've changed the partition reiserfs runs on.  That means comparison
with earlier runs is less valid.  Hans got me thinking the
benchmarks may be helpful for reiserfs developers, so I want
to cater to what is most useful for them.  

> the best thing to benchmark is the way you really use a system.

The mount options I typically use are noatime,notail,nodev,nosuid.

> If you have files that grow by small chunks but which are on average quite
> large then you will probably want to mount notails as it won't save any
> significant amount of space but can cost performance.  If you have any
> typical disk usage for home directories or maildir's then you'll want tails.

Thanks!

A "real world" workload I'm interested in is:
* 100k - 2mb files typically created by copy or parsed into existence.   
* Thousands of files in a directory, multiple big directories.
* files are typically accessed somewhat randomly and read in their entirety.
and
* I/O to large statically sized files (database reads/writes).

The benchmarks are meant to be a community contribution, rather 
than an evaluation of what's best for a workload I have.

-- 
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html


^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: best reiserfs mount options for generic benchmarking
@ 2002-09-14 16:53 rwhron
  2002-09-14 19:21 ` Russell Coker
  0 siblings, 1 reply; 6+ messages in thread
From: rwhron @ 2002-09-14 16:53 UTC (permalink / raw)
  To: bofh; +Cc: reiserfs-list

> http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark

hm, looks like i should update to bonnie++1.02c.
Any suggestions?

-- 
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html


^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: best reiserfs mount options for generic benchmarking
@ 2002-09-14 22:34 rwhron
  0 siblings, 0 replies; 6+ messages in thread
From: rwhron @ 2002-09-14 22:34 UTC (permalink / raw)
  To: russell; +Cc: reiserfs-list

> Good benchmarking takes serious amounts of time.  

Yes.  I appreciate the work you've put into bonnie++ to
make it better.

> You don't just run a benchmark once and store the results.  You have to 
> run benchmarks several times to measure the divergance of the results.  

I run bonnie++ and tiobench 3 times each and average the results.
dbench is run 5 times with the high/low/average noted.

> Also you have to have them come from a known state for best results, 
> EG you might reboot, mkfs the file system, then run the benchmark.  

That is basically how i do it.  On my web page of results I
try to make it clear that although i'm careful with the
benchmarks, they may not represent realistic loads.  My 
audience for the page is somewhere between the technical
user and the kernel developer.  Most of the kernel hackers
have a good feel for what the common benchmarks do.  The
fs developers probably understand the i/o benchmarks well
too.  I generally only post when there is a large divergence.
Not to say the divergence is important, but just to raise
the level of awareness.  

EG the only performance related posting i recall posting
to reiserfs-list is the one that noted tiobench sequential
reads with a lot of threads had a 70% regression in 
2.4.20-pre2.  That regression wasn't in ext2/ext3.
Oleg mentioned the prealloc mount option.  

I could have just started the thread with, "is prealloc the 
default in 2.4.20-pre7?", because the mount option is obscure 
enough that most people don't know it exists (and therefore
won't use it).

> Benchmarks that represent real things or interesting corner 
> cases are useful to the developers.  

Yes, the benchmarks that people come up with to scratch
an itch are probably the best for getting a problem fixed.
EG someone notices that mp3's skip when they burn a CD.
Those tests truly are time consuming because a human has
to monitor the audio, etc.  I did some tests like that
about a year ago when I noticed a certain memory load
caused mp3's to skip, and the kernel hackers came up
with a fix.  

Also on my page 
http://home.earthlink.net/~rwhron/kernel/bigbox.html
i say something like "this isn't meant to compare filesystems, 
only kernels, because the system state when ext2 is benched
is different from ext3, which is different from reiserfs.
However from kernel to kernel, reiserfs should be in a
very similar starting state compared to previous runs."

Thanks for your comments and making me think more.
-- 
Randy Hron


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-09-16  4:28 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-09-14 11:09 best reiserfs mount options for generic benchmarking rwhron
  -- strict thread matches above, loose matches on Subject: below --
2002-09-14 16:47 rwhron
2002-09-16  4:28 ` Valdis.Kletnieks
2002-09-14 16:53 rwhron
2002-09-14 19:21 ` Russell Coker
2002-09-14 22:34 rwhron

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.