[trondheim-pts] please fix bonnie parsing...
Eric Sandeen
sandeen at redhat.com
Fri Dec 5 15:09:18 CST 2008
I was fairly aghast to look into the bonnie++ results you posted for the
latest "filesystem benchmark"
For example:
http://www.phoronix.com/scan.php?page=article&item=ext4_benchmarks&num=2
The graph labeled "Bonnie++ v1.03d 4GB Random Delete" piqued my
interest... this makes it sound like these filesystems were deleting
approximately 200 4GB files per second; something which ext3, at least,
is *nowhere* close to capable of doing.
On further digging, I see that you wish to report the random delete rate
bonnie tests, which FWIW has nothing to do with the 4GB size you passed
as the -s option; rather it is the -n option which controls this. I
believe that the default is around 16k empty files.
So, on the flip side, deleting only 200 empty files per second is in
fact way too slow, so I took a look at your parse-results.php for bonnie.
$test_parts = explode(",", $BENCHMARK_RESULTS);
...
switch($test_target)
{
case "SEQ_CREATE":
$BENCHMARK_RESULTS = $test_parts[2];
break;
case "SEQ_READ":
$BENCHMARK_RESULTS = $test_parts[4];
break;
...
The output of bonnie that you are parsing looks something like this:
Version 1.03c ------Sequential Output------ --Sequential Input-
--Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
inode.lab 4G 41945 54 42945 7 18943 4 39696 76 40775 4
202.8 0
------Sequential Create------ --------Random
Create--------
-Create-- --Read--- -Delete-- -Create-- --Read---
-Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
/sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
+++++ +++
inode.lab,4G,41945,54,42945,7,18943,4,39696,76,40775,4,202.8,0,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++
and it is that last line you are attempting to parse. You are looking
at fields 2,4,6,8,10, and 12, and labeling them as seq create, seq read,
seq delete... etc.
These are completely the wrong fields for the labels you have assigned.
If you wish to properly parse it, you need fields 14 (nr files, divided
by 1024), 15 (sequential creations per second), 17 (sequential reads per
second), 19 (sequential deletes per second) and so on.
In my run above, in fact, these happened so quickly that no output was
produced ("+++")
Please fix this, and perhaps retract or fix your report; filesystem
benchmarks are interesting but IMHO you do a disservice by so badly
mangling the results, which the slashdot crowd will then take as the
gospel truth. ;)
Thanks,
-Eric
More information about the trondheim-pts
mailing list