Hi all.

Pre-purchase question. I haven't bought an unraid license yet but I'm learning about cache drives and considering a small SSD for this purpose (120gb or less). My NAS won't get huge parallel data streams from multiple users. Mostly just one desktop and my HTPC system accessing simultaneously.

 

I'd like to have a cache drive to benefit from the perceived transfer speeds and I'm thinking I would probably have the cache drive dump it's contents to the array every couple of hours.

 

Can someone elaborate as to what the negatives/positives might exist between a small SSD vs a larger WD Red drive? For example, if I fill the SSD in my 2hr block, what perceivable difference would I see. In general, I'm trying to answer if this occasional performance hit might be outweighed by overall performance improvements delivered by the SSD.

 

I'm specifically comparing a 1gb Red @ $100 to 120gb SSD @ $90 or so.

 

Thanks very much.

 

 

 

If your primary reason for a cache is to get faster write speeds, there's little reason to use an SSD vs. a 1TB/platter drive (the Reds are all 1TB/platter units).    The areal density on the 1TB/platter drives can easily support writes at network speed for a Gb network ... so a faster drive wouldn't make any difference.

 

If you were doing transcodes, or other "local" work that was using the cache drive, the SSD would help;  but for what you've described it's not necessary.

 

As I assume you're aware, a cache drive has NO impact on read speeds from the array -- only on writes.

 

+1 What garycase said, and some other things to consider:

 

Plus for Platter drive:

1. Could be used as a hot spare, in case of emergency (You would want the cache drive to be as big or bigger then the other drives though, so unless your array is all 1TB drives, you would need something bigger)

2. No need to worry about running out of space before movers kicks in.

3. No need to worry about garbage collection/trim. I'm not sure where the Linux kernel in UnRaid is on this point. I know it used to be unable to trim SSD drives in UnRaid, so you needed to make sure you purchased an SSD with robust garbage collection...

 

Plus for SSD:

1. Runs cool (no added heat).

2. Uses less power.

3. Should provide better performance for mysql if you put a db on the cache drive (for sharing XBMC data, Newznab etc..).

 

Personally, I went with a 256GB SSD, and I have noticed a *significant* difference in transfer speeds on writes (My previous cache drive was *not* a cutting edge red drive, so not a fair comparison, but still a data point that helps me justify the drive ).

 

Also, it made a huge improvement for XBMC when I was sharing thumbnails. There was significant lag in displaying thumbnails on various XBMC boxes before I switched to an SSD. Now that XBMC has gone to storing thumbnails locally, this is no longer an issue, and I haven't bothered testing to see if it still makes a difference... Perhaps someone else can chime in here...

 

Just some more food for discussion

Thanks guys. Very helpful info.

I didn't mention that this is a living room system so perceivable noise is more important than size of the storage provided as long as the size of storage doesn't impact performance, and yes I do also plan to put my plug-in user data on the cache. So two pluses for SSD in this case (noise and plugin performance).

 

Is it reasonable to conclude that when the mover's kick in you receive similar performance to writing directly to an array with parity enabled (minus the cache boost assisting in write performance)?

 

 

The actual "write to protected array" speed is the same, whether you're doing it over the network (without a cache) or the mover is doing it from the cache.

 

From your perspective, writes should always be to the cache (at least for cache-enabled shares -- you have to set them to use the cache).

 

So in a scenario where I am writing a 200gb file to a 120gb cache drive, the mover kicking in won't effect the perceived MB/s write speeds I am seeing on my local desktop?