Benefits of Cache-Only vs Cache-Prefer?

[Crad]

Lately I've been wondering why someone might want to set a share to Cache-Only - say, for appdata or system share. But as far as I can tell, there's no additional benefits to a cache-only share over a cache-prefer share.

 

All I can deduce is that if you're using a cache-only and run out of cache space, the share won't be able to write anymore data. This seems like a massive drawback for every share I can think of. For instance, using it with your appdata share would cause dockers to cease functioning if the cache drive was full.

 

Unless someone else has more insight? The only way I can see cache-only being beneficial is if unraid has some kind of prioritization under the hood - but I don't believe it does.

 

 

[itimpi]

What may not be obvious is that the system can optimise access to a cache-only share so it gets a performance advantage over a cache-prefer setting.    One has to decide if this is an important factor.

[Hoopster]

9 minutes ago, Conrad Allan said:

The only way I can see cache-only being beneficial is if unraid has some kind of prioritization under the hood

The only real "advantage" is that nothing from a cache-only share ever gets moved to the array.  Some would prefer an out of space warning and a write failure to placing files on the array thus causing unRAID to look for them in multiple places.  This could result in the spin up of additional disks and a performance hit (likely not a large one).

 

With cache prefer, low space situations will cause data from that share to be written to the array; however, if sufficient space becomes available again on cache, Mover should move those files back to cache.  Not often, but sometimes Mover fails to move everything and you could still have some files from a share "stuck" on the array and needing manual cleanup.  This happened to me once.

 

My appdata share, for example, is set to cache prefer.

 

 

[Crad]

11 minutes ago, itimpi said:

What may not be obvious is that the system can optimise access to a cache-only share so it gets a performance advantage over a cache-prefer setting.    One has to decide if this is an important factor.

 

Interesting... do you know if anyone has tested this performance difference or if there's any unraid documentation on it?

[mgutt]

On 2/23/2021 at 12:24 AM, itimpi said:

so it gets a performance advantage over a cache-prefer setting

@Conrad AllanThis statement is simply wrong. Cache-Only has absolutely no impact on performance. It only limits the size of the share to the size of the used pool and disables the mover.

 

You can simply test it. Transfer a file to a share which uses Prefer and check your CPU load with htop (130 - 200 % load):

 

Now do the same with a share which uses Cache-Only (130 - 200% load):

 

There is only one method available to boost performance and this is enabling direct disk / pool access. Either by enabling Global Disk Shares or by adding a custom Share through the smb-extra.conf. Example:

 

[Music-Cache]
	path = /mnt/cache/Music
	comment =
	browseable = yes
	# Private
	writeable = no
	read list = 
	write list = marc
	valid users =  marc
	case sensitive = auto
	preserve case = yes
	short preserve case = yes

 

After restarting the array (or changing something of a shares settings, which restarts the SMB service), you will see a new share in your network:

 

And if you now copy a file to this new share, it directly points to the cache pool and bypasses the FUSE overhead (90 - 130% load):

 

 

 

[trurl]

On 2/22/2021 at 6:33 PM, Hoopster said:

sometimes Mover fails to move everything and you could still have some files from a share "stuck" on the array and needing manual cleanup.

Nothing can move open files, so if appdata, for example, winds up overflowing, mover won't be able to move it back unless Docker is disabled in Settings. This, to me, is one good reason to use cache-only, or to bypass user shares completely for some things and just specify a path to cache.

 

Another thing to consider when you do want to allow overflow is the Minimum Free settings for the user share and for cache. Unraid has no way to know how large a file will become when it chooses a disk for it. If a disk has less than Minimum Free, Unraid will choose another disk (if allowed by other settings). This is how overflow happens. If cache has more than Minimum, and the share is cache-prefer, cache will be chosen even if the file won't fit.

 

Best and simplest solution to all these considerations is to simply avoid filling cache.

[Crad]

Oh Thanks guys, @trurl you give a good argument there for setting Docker files to cache-only.

 

I don't think bypassing the share for a bit of performance is something I need though, thankfully!