How big should a cache array be?

[Verme123]

My server is mainly used for media sharing via Plex and file storage. I have about 80tb of data. I'm about to rebuild unraid tonight and I've got a 240gb ssd along with a 250gb m2. In raid 1, this will obviously be 240gb. Is there a rule of thumb how big a cache drive should be vs your data array(s)? I don't think i would fill up 240gb in a day before it's committed, but you never know.. thanks.

[trurl]

In addition to caching user shares, another, perhaps more important, use for fast storage is docker/VM (appdata, domains, system shares), so these will perform better and not keep array disks spunup since there are always open files with these.

 

You could even have separate pools, one for caching and one for those shares. That is how I do it.

 

 

[Verme123]

5 minutes ago, trurl said:

In addition to caching user shares, another, perhaps more important, use for fast storage is docker/VM (appdata, domains, system shares), so these will perform better and not keep array disks spunup since there are always open files with these.

 

You could even have separate pools, one for caching and one for those shares. That is how I do it.

 

 

I see, so make a 1 disk cache and use the other drive for docker containers? Can a drive drive not in the cache array be used for the docker containers? I have another ssd sitting around somewhere. I was going to 2x the cache drives as well as the parity just in case.

Edited November 19, 2021 by Verme

[trurl]

23 minutes ago, Verme said:

Can a drive drive not in the cache array be used for the docker containers? I have another ssd sitting around somewhere. I was going to 2x the cache drives as well as the parity just in case.

With Unraid, it is useful to make a distinction between the array, and pools. The array is the disks in the parity array, protected by parity. In addition to the parity array, you can have pool(s) (multiple pools supported in 6.9+). Cache was the original pool, but you can have additional pools besides cache. In fact, you can name pools however you want, so you don't really have to have one named "cache".

 

Cache was originally for caching user share writes, but people would also use it as a way to have faster storage, since it doesn't include parity and often SSDs are used. Now we can have multiple pools, named as we want, and use them however we want. And each pool can have multiple disks if configured as btrfs raid. The pools are not protected by the parity disk(s) that are in the array, but they can have redundancy with btrfs raid.

 

I have 2x500GB "cache" pool (more than I need but I had the SSDs), and 256GB nvme "fast" pool for dockers/VMs. The appdata, domains, system shares are configured to use the "fast" pool so dockers/VMs perform better and don't keep array disks spunup, as I mentioned before.

[Verme123]

2 minutes ago, trurl said:

With Unraid, it is useful to make a distinction between the array, and pools. The array is the disks in the parity array, protected by parity. In addition to the parity array, you can have pool(s) (multiple pools supported in 6.9+). Cache was the original pool, but you can have additional pools besides cache. In fact, you can name pools however you want, so you don't really have to have one named "cache".

 

Cache was originally for caching user share writes, but people would also use it as a way to have faster storage, since it doesn't include parity and often SSDs are used. Now we can have multiple pools, named as we want, and use them however we want. And each pool can have multiple disks if configured as btrfs raid. The pools are not protected by the parity disk(s) that are in the array, but they can have redundancy with btrfs raid.

 

I have 2x500GB "cache" pool (more than I need but I had the SSDs), and 256GB nvme "fast" pool for dockers/VMs. The appdata, domains, system shares are configured to use the "fast" pool so dockers/VMs perform better and don't keep array disks spunup, as I mentioned before.

That is fantastic info, just what I will do myself, thanks a ton!