SSDs vs. high performance HDDs

[wug]

I've been looking at drives for my cache pool and I can't decide if I want to buy bigger, high performance HDDs or smaller mid-range SSDs.

 

My thinking is that WD Black drives and other drives on the same tier show write speeds in the ballpark of 150MB/s. Thus, on a Gigabit LAN, I could saturate my connection with 125MB/s of data to the server, and the drive would be able to keep up. I could further increase the maximum write potential for writes generated on the server itself if each cache drive was actually two smallish drives in a hardware RAID-0 configuration.

 

Does anyone have any strong opinions on the matter? Would I be better off with an SSD or two high performance HDDs in RAID0 configuration? For the same amount of money, the SSD option would give a much higher performance while the HDD option would give me much more space.

[testdasi]

I've been looking at drives for my cache pool and I can't decide if I want to buy bigger, high performance HDDs or smaller mid-range SSDs.

 

My thinking is that WD Black drives and other drives on the same tier show write speeds in the ballpark of 150MB/s. Thus, on a Gigabit LAN, I could saturate my connection with 125MB/s of data to the server, and the drive would be able to keep up. I could further increase the maximum write potential for writes generated on the server itself if each cache drive was actually two smallish drives in a hardware RAID-0 configuration.

 

Does anyone have any strong opinions on the matter? Would I be better off with an SSD or two high performance HDDs in RAID0 configuration? For the same amount of money, the SSD option would give a much higher performance while the HDD option would give me much more space.

 

The connection between your VM and your share is 10Gb so you need SSD to fully utilise that.

 

I have tried RAID0 in the past and will never do that again. It is like having a gun next to your head cuz it can fail any time (and in my case, it did, in a week, because windows crashed and not disk issues).

 

The most benefit of SSD is not pure sequential speed but random access / seek speed.

[BRiT]

I voted other, as there doesn't seem to be an option for 1 large high performance SSD.

 

There also isn't an option for NVME for obscene performance SSDs.

 

It doesn't make sense to have rotational drives as the cache drive. The latency is too high.

[John_M]

I voted for a pair of low to mid range SSDs because that's what I use and it suits my needs. It's fast, safe and capacious enough to function well as an unRAID write cache and be home for three or four dockers. My virtualisation needs are minimal.

[testdasi]

Attached is a quick proof that VM-tower link is definitely more than 1Gb/s. 

 

[wug]

Attached is a quick proof that VM-tower link is definitely more than 1Gb/s. 

 

That's only slightly faster than the sequential read/write speed of the 6TB WD Black! I don't use any VMs that require high performance nor do I plan to, but I would like to use the cache to store things like optimized Plex versions of recent shows, and other things of that nature. My priority is leaning toward capacity over performance, so I'm trying to gauge if there is any very compelling reason to lean one way or another.

[garycase]

... I'm trying to gauge if there is any very compelling reason to lean one way or another.

 

As you've already noted, the transfer speeds you can get with a modern hard drive with platter densities over 1TB/platter are excellent.  There's certainly no compelling reason to use an SSD as a cache for writes to the array, or for the usage you noted vis-à-vis Plex shows.    However, as a VM and Docker store, an SSD would have significant performance advantages with the internal usage, NOT because of the much higher write speeds, but because of the dramatically better access times for every disk I/O.    Whether or not that's "compelling" depends on your specific usage ... but in most cases I'd tend to think it doesn't really matter.

 

Note that you could also mix the choices -- use a large rotating platter drive together with an SSD, with the VM and Docker stores assigned to the SSD.

 

[mr-hexen]

However, as a VM and Docker store, an SSD would have significant performance advantages with the internal usage, NOT because of the much higher write speeds, but because of the dramatically better access times for every disk I/O.

 

THIS. A spinner could never hope to keep up with an SSD when it's getting hammered with requests from all over (Docker, VM's, caching writes, etc.)

[wug]

... I'm trying to gauge if there is any very compelling reason to lean one way or another.

 

As you've already noted, the transfer speeds you can get with a modern hard drive with platter densities over 1TB/platter are excellent.  There's certainly no compelling reason to use an SSD as a cache for writes to the array, or for the usage you noted vis-à-vis Plex shows.    However, as a VM and Docker store, an SSD would have significant performance advantages with the internal usage, NOT because of the much higher write speeds, but because of the dramatically better access times for every disk I/O.    Whether or not that's "compelling" depends on your specific usage ... but in most cases I'd tend to think it doesn't really matter.

 

Note that you could also mix the choices -- use a large rotating platter drive together with an SSD, with the VM and Docker stores assigned to the SSD.

 

Can you assign shares to use specific cache disks like you can with shares on the array? If that's the case, then an SSD/HDD pair is definitely the best option.

 

I would like the performance bump I'd get from an SSD, but I'd also like to have a high-capacity off-array store which improves performance in other ways. For example, I've been trying to get as much media as possible in x265 and I've been converting files to x265 because the space savings is huge, but until I upgrade my other internals, it would be nice to also keep optimized versions of things like what's On Deck in Plex. That way I could have tiny x265 files for long-term storage, but I wouldn't have to violently assault my processor every time I want to watch the latest episode of a TV show on my Chromecast.

[testdasi]

Can you assign shares to use specific cache disks like you can with shares on the array? If that's the case, then an SSD/HDD pair is definitely the best option.

 

I would like the performance bump I'd get from an SSD, but I'd also like to have a high-capacity off-array store which improves performance in other ways. For example, I've been trying to get as much media as possible in x265 and I've been converting files to x265 because the space savings is huge, but until I upgrade my other internals, it would be nice to also keep optimized versions of things like what's On Deck in Plex. That way I could have tiny x265 files for long-term storage, but I wouldn't have to violently assault my processor every time I want to watch the latest episode of a TV show on my Chromecast.

Wouldn't that just be Unassigned Devices?

[wug]

Can you assign shares to use specific cache disks like you can with shares on the array? If that's the case, then an SSD/HDD pair is definitely the best option.

 

I would like the performance bump I'd get from an SSD, but I'd also like to have a high-capacity off-array store which improves performance in other ways. For example, I've been trying to get as much media as possible in x265 and I've been converting files to x265 because the space savings is huge, but until I upgrade my other internals, it would be nice to also keep optimized versions of things like what's On Deck in Plex. That way I could have tiny x265 files for long-term storage, but I wouldn't have to violently assault my processor every time I want to watch the latest episode of a TV show on my Chromecast.

Wouldn't that just be Unassigned Devices?

 

Can user shares on the array also be on disks managed through Unassigned Devices? Although I guess it would make more sense add a second folder pointing to, for example, an "optimizedmedia" share in each of my Plex libraries and have optimized versions be saved there. That's kind of what I did when I was running Plex off of my laptop with my media on external hard drives; I had a second set of media folders directly on my laptop where it would store "optimized" original quality copies of shows that were On Deck in Plex.

[drdobsg]

Fairly new to the cache pool scene, but I have been reading a lot about this in the forums lately.  It seems to me the ideal would be two 1GB WD Black drives in BTRFS Raid-1 as the normal cache pool and then have a single SSD for the dockers.  I assume you can run dockers from the SSD via unassigned devices?  Then have a backup procedure backup the SSD to the array.  So far i don't see a need to have real time disk failure protection for the Docker drive, a nightly backup should be good enough for me. Maybe if you have an important VM running on it then you might want to mirror it.

[testdasi]

Fairly new to the cache pool scene, but I have been reading a lot about this in the forums lately.  It seems to me the ideal would be two 1GB WD Black drives in BTRFS Raid-1 as the normal cache pool and then have a single SSD for the dockers.  I assume you can run dockers from the SSD via unassigned devices?  Then have a backup procedure backup the SSD to the array.  So far i don't see a need to have real time disk failure protection for the Docker drive, a nightly backup should be good enough for me. Maybe if you have an important VM running on it then you might want to mirror it.

 

I think you can install dockers on SSD via unassigned devices. I tested it briefly and it seemed to work on the surface but did not do any deep tests.

 

And with Turbo Write turned on, your array performance will be reasonably fast (I can get north of 100MB/s, even on the "long stroke" ends of the various drives) so why bother with using small-capacity HDD as cache anyway?

It will just occupy 2 device slots (so you potentially need a more expensive license) for marginal gain.

 

If you already have the £££ to buy the more expensive license then why not just buy SSD to use as cache instead?

Dockers, VMs and cache all can share the same SSD / SSDs. There's barely any performance hit (my test rig uses a very old Kingston 128GB SSD => how old? it's SATA2!).

 

I think if cost is a concern for you then to be honest, you will save more by just using SSD as cache and put VM + dockers on it since you are gonna get an SSD anyway.

And if the cache is full (because of dockers + VM), unRAID will just automatically write straight onto the array.