iozone-ing an SSD (Re: Using an SSD "disk" for /)

[Julian Elischer]

On 11/5/10 4:13 PM, Mikhail T. wrote:
> 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!

I have no idea about that brand of ssd, but the industry benchmark for 
disk-replacement
SSDs at the moment are the newest intel  drives.
>      -mi
>