April 21, 20224 yr I have just added two spare SSD's. I setup one as 'apps' to store appdata, system, docker image, etc... and a public share with common files, installers, etc... Another to be used as a write_cache for files written to the server. Maybe I don't understand the settings properly, but when set the write cache to 'Prefer', and manually run the Mover, it's writing files to the cache drive from the array. Is the only way to have the opposite occur, to set the share to 'Yes' and risk it filling up completely? Edited April 21, 20224 yr by cam94z28
April 21, 20224 yr Prefer will move files to the cache. This is normal. If you set the cache to yes the files will initially go to the cache and move to the array when you run the mover. If you look under setting and scheduler you can set the mover to run when you want. Personally I run the mover once a day in the early morning.
April 21, 20224 yr Worth mentioning there is also the CA mover tuning plug-in that gives you some additional flexibility on when you want to run the mover.
April 21, 20224 yr Community Expert Solution 14 minutes ago, cam94z28 said: set the share to 'Yes' and risk it filling up completely? As already mentioned, yes is the required setting to get files moved from cache to array. As for filling up completely, whether you set a share to prefer (to have on cache) or yes (move to array), it will overflow to the array based on the Minimum Free setting for the pool (cache). You must set it larger than the largest file you expect to write to the pool. Minimum Free doesn't control how much space is kept free. Instead, it controls how much space must be free for the pool to be chosen. If the pool doesn't have the minimum, it will write to the array instead (for cache-yes or prefer). Each user share has a Minimum Free also. If a disk doesn't have the minimum, another will be chosen.
April 21, 20224 yr Author Thank you. The word "Prefer" makes it confusing, but the text at the right in the share settings makes it clear. I changed to 'Yes', stopped the mover from the terminal ('sudo mover stop', and re-ran it. Now, it is reading from the cache and writing back to the array. I will try the mover tuning plugin and also install the appdata backup plugin, as my pools are single-drive. Just out of curiosity, with things set to 'Yes', is there any protection from the drive filling up during the process? Edited April 21, 20224 yr by cam94z28
April 21, 20224 yr Community Expert Just now, cam94z28 said: is there any protection from the drive filling up during the process? See my post just above yours
April 21, 20224 yr Author 1 minute ago, trurl said: See my post just above yours I was actually replying to Gregorg but forgot to quote. Thank you. That makes sense. I will increase minimum free space, and go with it.
April 21, 20224 yr Community Expert 9 minutes ago, cam94z28 said: Thank you. The word "Prefer" makes it confusing, but the text at the right in the share settings makes it clear. I changed to 'Yes', stopped the mover from the terminal ('sudo mover stop', and re-ran it. Now, it is reading from the cache and writing back to the array. This is one reason that additional text was added as many people do not read the Help text which gives the fuller explanation of the settings. Originally only the No and Yes settings existed. When the mover behaviour was enhanced to support the additional options that are now provided by the Only and Prefer settings there was too much legacy code and documentation to consider changing the Yes and No options so new keywords had to be found for the new options. I suspect if we were starting with a clean sheet the Yes and Prefer settings would be the other way around.
April 21, 20224 yr I have advocated before to change things completely, where each share has 2 settings. Initial file placement, and mover enabled or not. If mover is enabled for a share, a new field for destination would appear. That would simplify explanations, and allow for pool to pool mover configuration.
November 13, 20241 yr High guys, using Unraid now for half a year and was before on Windows with a software called PrimoCache: https://www.romexsoftware.com/en-us/primo-cache/index.html This was excellent for configuring your read and write cache SSD. It also used RAM for the cache and you could set read / write cache sizes. A neat feature was something like "predicted" read cache. So new files would go on the cache, would be written to HDD after a defered time BUT would remain on the cache. Also it loads much accessed data from the HDD into the cache if you access it. This has boosted the accesstime, read & write speed's to my NAS significantly! It also showed a statistic with an cache "hit rate", so a percentage how it predicted the files being used (from cache or not). The percentage was arround ~70% in my use case. Currently i have setup unraid share with an cache as primary storage, hdds/array as secondary with high-water and mover action "Cache -> Array". As documented, new files get's written to the fast cache and move on schedule to the array. Is there a similar functionallity in unraid like PrimoCache does (a smart cache)? Can the cache in unraid set to leave last written files also on cache and just copy (backup) it to the array and not move them? Sorry if this was already answered, but i am not so deep in the unraid caching mechanism.
November 13, 20241 yr Community Expert This is not a standard Unraid feature with the main array but you should be able to get similar functionality by using a ZFS format redundant pool as Primary storage (with no Secondary storage) using its Arc facility.
November 15, 20241 yr thx for the hint to zfs (ARC & ARCL2). Was hoping that there is an plugin which can a real cache to any file system array, but sadly it seems there is no such plugin. Dont want to use zfs for just 1x nvme + 2x hdds. Nor i need the other features like snapshots...
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.