Jump to content

HDD vs SSD for cache pool?


Ned

Recommended Posts

Since with v6 we can now run VMs it is obviously ideal to have those VMs run in a cache pool for added performance.  However, when you start getting into VMs, depending on what you are doing, you might need a fair bit of disk space.

 

While SSDs are the ideal performance-oriented choice, when you start getting into the 500+GB size range, they become very expensive, especially when you need to buy two in order to gain the redundancy of a cache pool.

 

What about using some quality 7200 RPM disks like the WD Red Pros?  I was thinking that a pair of 2TB Red Pros would be a great balance of performance and reliability for an always-on server like this... and they would also give the necessary disk space for running multiple VMs at a very reasonable price point...

 

Thoughts???

 

Link to comment

SSDs provide a very significant performance advantage over spinners for VM and Docker applications. I run an SSD for Dockers and VMs (250G), and have a older non-array spinner (1T) for temp workspace in the server. Those sizes are plenty for me.

 

I am not sure about hybrid drives. Don't think their SSD portion is big enough.

Link to comment

SSDs provide a very significant performance advantage over spinners for VM and Docker applications. I run an SSD for Dockers and VMs (250G), and have a older non-array spinner (1T) for temp workspace in the server. Those sizes are plenty for me.

 

I am not sure about hybrid drives. Don't think their SSD portion is big enough.

 

If you mix one SSD and one HDD like that in a cache pool can you designate which drive is used for what purpose?  I thought in a cache pool data is written across multiple drives for redundancy so then the HDD would be the bottleneck wouldn't it?

Link to comment

SSDs provide a very significant performance advantage over spinners for VM and Docker applications. I run an SSD for Dockers and VMs (250G), and have a older non-array spinner (1T) for temp workspace in the server. Those sizes are plenty for me.

 

I am not sure about hybrid drives. Don't think their SSD portion is big enough.

 

If you mix one SSD and one HDD like that in a cache pool can you designate which drive is used for what purpose?  I thought in a cache pool data is written across multiple drives for redundancy so then the HDD would be the bottleneck wouldn't it?

 

My SSD is set up as the cache disk (it is not in a pool). The spinner is a separately mounted device (not array or cache).

 

I believe that when you mix two drives in a cache pool, you'd get the capacity of the smallest one. Now if you have 3 disks, you get the most capacity such that data is able to be stored on 2 devices. 2 240G, and a 120G, would net you 300G

 

I don't know the rules for mixing SSDs and non-SSDs in a cache pool. But I assume it is fine but that performance would only be as good as the slower disk. So I would not recommend it.

Link to comment

SSDs provide a very significant performance advantage over spinners for VM and Docker applications. I run an SSD for Dockers and VMs (250G), and have a older non-array spinner (1T) for temp workspace in the server. Those sizes are plenty for me.

 

I am not sure about hybrid drives. Don't think their SSD portion is big enough.

 

If you mix one SSD and one HDD like that in a cache pool can you designate which drive is used for what purpose?  I thought in a cache pool data is written across multiple drives for redundancy so then the HDD would be the bottleneck wouldn't it?

 

My SSD is set up as the cache disk (it is not in a pool). The spinner is a separately mounted device (not array or cache).

 

I believe that when you mix two drives in a cache pool, you'd get the capacity of the smallest one. Now if you have 3 disks, you get the most capacity such that data is able to be stored on 2 devices. 2 240G, and a 120G, would net you 300G

 

I don't know the rules for mixing SSDs and non-SSDs in a cache pool. But I assume it is fine but that performance would only be as good as the slower disk. So I would not recommend it.

 

Yes, this is my understanding as well... either both disks as SSD or both as HDD makes the most sense.

 

I'm hearing many people in the forums tell me that there are many reported issues with the BTRFS file system and they are recommending against using a cache pool.  They say I'm better off using a single cache disk running XFS.  Limetech has not made any statement about this and all of the website material and supporting v6 documentation says that cache pool is the way to go.

 

Currently I don't have any cache at all... so since I'm going to be buying new disks I'm looking for a recommendation on what to do.  I will use a couple of dockers and VMs so I will need a fair bit of space and large SSDs are expensive.

 

It's the issues I'm hearing about BTRFS that I'm starting to wonder about now...

Link to comment

Yes, this is my understanding as well... either both disks as SSD or both as HDD makes the most sense.

 

I'm hearing many people in the forums tell me that there are many reported issues with the BTRFS file system and they are recommending against using a cache pool.  They say I'm better off using a single cache disk running XFS.  Limetech has not made any statement about this and all of the website material and supporting v6 documentation says that cache pool is the way to go.

 

Currently I don't have any cache at all... so since I'm going to be buying new disks I'm looking for a recommendation on what to do.  I will use a couple of dockers and VMs so I will need a fair bit of space and large SSDs are expensive.

 

It's the issues I'm hearing about BTRFS that I'm starting to wonder about now...

 

I run XFS on my cache SSD.

 

HERE is all you need for your cache disk. 10G Docker, 30G VM (two if you need two), and you stiil have 170-200G for files. It doesn't have to be huge or expensive. This is perfect size for $99.

 

And if that's not enough, $179 and you've got 500G SSD. You can have 10 VMs and still plenty of room for files and Dockers.

Link to comment

Just thought I should provide some official comment on this that mixing an HDD and SSD in cache pool is possible, but not recommended.  You will be limited to the performance of the HDD and the capacity of the SSD (basically the lowest common denominator becomes your bottleneck).

 

In short, SSDs provide two big advantages for the cache over HDDs:

 

1)  They do not require to "spin up"

2)  They provide far greater speed for virtual machines and applications than traditional HDDs

 

In the end, using HDDs or SSDs is a personal choice, not a requirement.  Depending on your exact usage, the benefits may or may not be apparent.  Generally my advice is as follows:

 

If you're just using this box as a traditional NAS, you should go with HDDs for your cache.

 

If you're using the box for NAS + some apps through Docker, then HDDs are fine, but SSDs may give you better performance for certain apps.  Personal choice.

 

If you're using this box as your primary workstation/gaming rig, NAS, and apps, then SSDs are really advantageous, but still not required.

Link to comment

Thanks for the advice guys, I really appreciate it.  Part of why I was thinking I would need a lot of space for one of my VMs was because I currently run a separate server as a DVR, connected to several IP cameras.  I was worried about the following:

 

1) I heard SSD drives are not good for DVR applications due to the constant adding and deleting of small files

2) There is an option to archive video files to a NAS and I was thinking of using unRAID array for that, however I was concerned that if I were to cap either the amount of space or the length of time that videos are archived for, it would result in constantly deleting old video files and replacing them with new ones on the array, resulting in a lot of file fragmentation (I don't know how unRAID deals with that).

 

What are your recommendations regarding this type of application?  I'm starting to think that a small VM on SSD for the DVR application would be ideal to store "recent" video files and then use the array to archive older files and age them out as appropriate but per my point #2 I'd like to understand if this would have any negative impact on the array?

Link to comment

How many video streams are being recorded? A modern HDD can handle 5-10 streams. Modern SSDs have 3 year warranties. The first option is to write directly to the HDD bypassing the cache for video streams. If there are too many streams for HDD then plan on replacing the SSD in 3 years.

Link to comment

How many video streams are being recorded? A modern HDD can handle 5-10 streams. Modern SSDs have 3 year warranties. The first option is to write directly to the HDD bypassing the cache for video streams. If there are too many streams for HDD then plan on replacing the SSD in 3 years.

 

Streams are only recorded when motion is detected so I think SSD will be fine especially if I use a drive like the Samsung 850 (Evo has 5 year warranty with 75 TBW and Pro has 10 year warranty with 150 TBW).

 

My concern now is more about archiving clips on the array... I will set it up so that clips are deleted after 6 months, which means that eventually old files will constantly be deleted from the array with new files constantly added to the archive... will that cause any issues with the array?  File fragmentation, etc. that I should be concerned about?  How does unRAID deal with file fragmentation?

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...