Confused on unRAID Cache Drives.


Recommended Posts

I could use some advice- so thanks upfront to anyone offering their opinions.

 

For me, I am a bit confused on the advantage/utility of a cache drive utilizing a SSD. I have a small server for home use (3x4TB + 1x 4TB parity, all IronWolf SATAs) and definitely going to add an SSD (primarily for VMs). I also have a few small SAS drives (2x 600GB + 2x 450GB), which I am going to include for various small tasks that will probably remain unassigned drives (for scratch files). The controller is a Dell H700 RAID adapter in a Dell PowerEdge T310 with 16GB of DDR3 RAM. And I am running gigabit (1gbs) ethernet.

 

Let me say upfront: I am not concerned with loosing a VM or a what I call a "scratch file." I -am- concerned for my digital photo library and digital documents and backups (most of which will come by moving from a client/laptop and moved onto the server) which will be in the drives with parity covering them. I am not moving (or creating) lots of videos, have few media files (so far), and not expecting that to increase significantly for the next 3-5 years. (I do a little scientific computing and 3D graphics, but nothing like commercial groups do.)

 

But what I am unclear on is what value I would get out of an SSD that would be used for disk cache considering these conditions/use cases. As I understand it, most of the time the unRAID cache is  "flushed" is when the "mover" program runs (default is once at night). And until "mover" runs, the files "sit" on the SSD. Is that correct?

 

And yes, I would expect to see improved performance with cache when moving smaller files, but I don't really do that all that often. I tend to "build up" a cluster of files, and move them all at once from the client... and more often than not, I need to move files down from the server to work on them. I then move the modified/edited (photo) files back up to the server. In fact, I often need to move larger files (backups, video files, digital documents, and clusters of digital photos ~ 300-600GB in size) fairly often, and when moving those files are larger than the size of the SSD that would be used as a cache. But I also wouldn't care if they move from the client to the server overnight. Also, if I am moving individual files - I'm more interested in them being on the "NAS Drive" than bouncing from a cache drive to the "NAS Drive". 

 

So, I think I'm better off just sizing my SSD large enough for the number of VMs I plan to use/run - and run the array without cache.

 

Should I rethink that idea?

And is there anything else I should consider in sizing my SSD... like "nextcloud/owncloud" considerations, docker apps or other apps/tools... ?

 

To compound and confuse this discussion - I have a 120GB SSD now, but thinking I need a 250-512GB SSD, but if I were to find a compelling reason, I'd just get a 1TB SSD. Also, based on the Dell T310 architecture, the max speed on any one drive is 6gbs, and NVMe is not supported as far as I know.

 

 

Link to comment
14 hours ago, rollieindc said:

I could use some advice- so thanks upfront to anyone offering their opinions.

 

For me, I am a bit confused on the advantage/utility of a cache drive utilizing a SSD. I have a small server for home use (3x4TB + 1x 4TB parity, all IronWolf SATAs) and definitely going to add an SSD (primarily for VMs). I also have a few small SAS drives (2x 600GB + 2x 450GB), which I am going to include for various small tasks that will probably remain unassigned drives (for scratch files). The controller is a Dell H700 RAID adapter in a Dell PowerEdge T310 with 16GB of DDR3 RAM. And I am running gigabit (1gbs) ethernet.

 

Let me say upfront: I am not concerned with loosing a VM or a what I call a "scratch file." I -am- concerned for my digital photo library and digital documents and backups (most of which will come by moving from a client/laptop and moved onto the server) which will be in the drives with parity covering them. I am not moving (or creating) lots of videos, have few media files (so far), and not expecting that to increase significantly for the next 3-5 years. (I do a little scientific computing and 3D graphics, but nothing like commercial groups do.)

 

But what I am unclear on is what value I would get out of an SSD that would be used for disk cache considering these conditions/use cases. As I understand it, most of the time the unRAID cache is  "flushed" is when the "mover" program runs (default is once at night). And until "mover" runs, the files "sit" on the SSD. Is that correct?

 

And yes, I would expect to see improved performance with cache when moving smaller files, but I don't really do that all that often. I tend to "build up" a cluster of files, and move them all at once from the client... and more often than not, I need to move files down from the server to work on them. I then move the modified/edited (photo) files back up to the server. In fact, I often need to move larger files (backups, video files, digital documents, and clusters of digital photos ~ 300-600GB in size) fairly often, and when moving those files are larger than the size of the SSD that would be used as a cache. But I also wouldn't care if they move from the client to the server overnight. Also, if I am moving individual files - I'm more interested in them being on the "NAS Drive" than bouncing from a cache drive to the "NAS Drive". 

 

So, I think I'm better off just sizing my SSD large enough for the number of VMs I plan to use/run - and run the array without cache.

 

Should I rethink that idea?

And is there anything else I should consider in sizing my SSD... like "nextcloud/owncloud" considerations, docker apps or other apps/tools... ?

 

To compound and confuse this discussion - I have a 120GB SSD now, but thinking I need a 250-512GB SSD, but if I were to find a compelling reason, I'd just get a 1TB SSD. Also, based on the Dell T310 architecture, the max speed on any one drive is 6gbs, and NVMe is not supported as far as I know.

 

 

 

Although the cache drive concept was originally implemented, as its name suggests, to cache writes to the array on a per share basis, it is also very commonly used now as the home for the appdata share which is where all the docker configurations live.  Depending upon the nature of the docker, performance of dockers is much better if the cache drive is an SSD, particularly for those dockers that do file downloading, editing, encoding, etc.

 

I have some dockers that download files, but, I also use the Handbrake docker for encoding movies and its watch folder and output folders are on the cache drive as well.

 

As you mentioned, you could also host VMs on the cache drive, although, for heavily-used VMs that require a lot of storage and/or disk operations, some opt for a separate SSD per VM or one for all VMs for lighter VMs.  These are commonly configured as unassigned devices.

 

You can now create cache pools of multiple drives as well that offer some redundancy for appdata or if you are caching a large amount of files or a smaller amount of large files until such time as the mover moves them to the parity-protected array.

 

The bottom line is that the "cache" drive is now used for more than just file caching to speed up initial writes.

 

Personally, I have two SSDs in my main system; one 256GB for appdata/dockers (the "cache" drive) and another 480GB for VMs (an unassigned device). I don't cache any writes to the array.

 

 

Edited by Hoopster
  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.