Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Nov 2010 19:13:05 -0400
From:      "Mikhail T." <mi+thunw@aldan.algebra.com>
To:        Julian Elischer <julian@freebsd.org>
Cc:        fs@freebsd.org
Subject:   iozone-ing an SSD (Re: Using an SSD "disk" for /)
Message-ID:  <4CD48F81.1080201@aldan.algebra.com>
In-Reply-To: <4CD09830.3030400@freebsd.org>
References:  <4CD04AEC.8040607@aldan.algebra.com> <4CD051A9.7090200@freebsd.org> <4CD0660E.2000102@aldan.algebra.com> <4CD06C4B.80100@freebsd.org> <4CD0895A.5030402@aldan.algebra.com> <4CD09830.3030400@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello!

So, after an earlier inquiry, I went ahead and purchased an SSD
(Crucial's CTFDDAC128MAG-1G1) and put it to some testing today.

The computer is Dell Poweredge 2900, running FreeBSD-8.1/amd64 (the
October 10th snapshot). Generic kernel. The system drive (for now) is
traditional "real" HD -- a 15K RPM by Fujitsu (MAX3073RC), I ran `iozone
-a' 4 times:

    1. On /var/tmp -- freshly newfs-ed by the sysinstall on the Fujitsu
drive (/dev/da0).
    2. On the SSD (/dev/ad4) freshly newfs-ed by me without ANY options
(no softupdates).
    3. On the SSD (/dev/ad4) freshly newfs-ed by me with very large -e
and -a options. Reading the man-page, I figured, any parameters
mentioning "cylinders" can be set to very large values...
    4. On the SSD (/dev/da1) connected to the server's mpt-controller,
rather than the plain SATA port -- using the same filesystem created in
3. above (no reformatting). (The 2.5" can't be secured in the 3.5" slot
and is simply hanging in the air on the SATA/SAS connectors.)

The results can be found in 4 HTML files found at:
http://aldan.algebra.com/~mi/io/ (The original iozone-created Excel
files are there too.)

They puzzle... Fujitsu, for example, is not an OBVIOUS loser -- it beats
the SSD in a number of file-size record-length combinations. I also
can't explain, the differences between different takes on the SSD.

And, lastly, there is a surprising (to me) spike in "Record Rewrite"
throughput -- for both SSD and HD -- for large files when the reclen is
64. Using reclen of 128 results in much worsening throughput --
especially for the Fujitsu.

I wonder, if these data can be exploited to come up with better newfs
parameters for the modern disks (SSD and not)... Comments? Thanks!

    -mi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CD48F81.1080201>