Tried an SSD as a data disk.....

I had a spare 16GB SSD (SLC, and not the fastest thing in the world, but good enough) so I thought I'd try it out as a data disk in unRAID 4.5

I benchmarked it before adding it to the array, and got 75MB/sec writes and 110 MB/sec reads.

Parity is a 320GB WD Blue (7200RPM, 16MB cache)

I benchmarked the parity drive before adding it to the array, and got 100 MB/sec writes and 115 MB/sec reads.

Both drives are on different SATA channels on the mobo, and both were empty.  They are the only 2 drives in the array.

Parity calc started at 105MB/sec... tapering off to end at 52MB/sec.

Writes to the SSD after parity was finished were 40MB/sec.

Unfortunately, the SSD is not large enough to make it a parity disk and I don't have 2 of them.

Writes to the SSD after parity was finished were 40MB/sec.

What do you use as a benchmark to get this number? I see allot of numbers people report and mine never come near this.

My only way to test some of this is through real world tests with an rsync between machines to a specific disk share. Then I can benchmark throughput, pauses and get an average sense of non interrupted transfer rate.

I'm also on the edge of purchasing two of the Intel 40G ssd's. Zipzoomfly has a good price on them.

I'm considering the swap out my system drives for these or the vertex 60G units ittle by little.

Unfortunately, the SSD is not large enough to make it a parity disk and I don't have 2 of them.

hdparm -N

command on it.  (reset it when done with the tests... )

What do you use as a benchmark to get this number?

I'm doing an internal copy using dd.  I want to get raw parity-protected speed independent of LAN for now.

You can always set the HPA on the larger 320G parity disk too make it look the same size as the SSD by using the

hdparm -N

Great idea.....

With SSD as parity, and the WD Blue as data, first parity calc ran at about 75MB/sec.

The second parity check ran at 102MB/sec.

Internal write test using dd with were 37MB/sec.

Testing over the LAN:

Read speed was 57.5MB/sec.

Write speed was 34.5MB/sec.

And the "spikiness" when writing was apparent... see this image:

I tried manipulating the unRAID tunables, as well as the disk scheduler, and could while I could get worse results, no combination gave more than about 5% better performance, and those were not always consistently better.

I just made a special kernel build of kernel 2.6.32.7 with unRAID 4.5.1, in order to try the new flushing system introduced in the 2.6.32 kernel, doing away with pdflush.

Wow.

All the "spikiness" when writing to the array over the LAN is gone.

Compare this graph:

to the old one using the exact same system, but with the older kernel:

Write speeds were 20% faster too.

Wow...  way less need for a cache drive now.   Just as well I never bothered to add one. 

By using the SSD as a cache parity disk, eliminating rotational delays and seeking, I was able to get darn close to the theoretical maximum.  Consider this:

If you are writing 1GB to unRAID, you have to read 1GB and write 1GB.  There has been a lot of discussion of the optimization from reading a bunch at once, then queuing the writes and writing them back in a batch.

Consider a drive (such as mine) that reads at 100MB/sec and writes at 75MB/sec.  So theoretically it takes 10 seconds of reading and 13.3 seconds of writing for a total of 23.3 seconds to write 1GB to unRAID.  That means 43MB/sec of maximum theoretical throughput.  Using this formula, and I/O specs for your drives, you can easily calculate the maximum theoretical throughput for your system.  

I was able to do consistently over 40MB/sec (i.e. 93% of theoretical max) with the SSD as cache parity, and the WD Blue as data.  I'll try to scrounge up some other drives to do some more testing.

By using the SSD as a cache disk

Did you mean parity in your previous post?

Did you mean parity in your previous post?

Yes... fixed it.

I swapped the drives so the WD Blue is parity, and the SSD is data. All results were essentially the same.... sustained ~40MB/sec transfers and no spikiness.

Unfortunately, I don't have another SATA drive laying around at the moment to test it with two rotating media.

Did you mean parity in your previous post?

 

Yes... fixed it.

There's still one instance of the "By using SSD as cache" in your post, BubbaQ.

Cross post link as the subject matter seems to tie in together

http://lime-technology.com/forum/index.php?topic=5831.msg56134#msg56134