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>