Faceman

/boot/config is on the boot USB yes. you can manage it from the terminal or from the web ui with the file manager. You can also access it over the network if you enable "export" in the settings for the flash device if you are mover comfortable with that, but it's good to disable that when not using it.

Not yet, that is a feature of OpenZFS2.3 which is still very, very new for public use. TrueNas got it included first because they helped the OpenZFS team get it to production. ZFS expansion does still have a few caveats attached to it, it's not a magic bullet solution to ZFS's drawbacks but it does help massively. It could be in Unraid 7.1 , but no guarantees on that as a lot of testing has to be done before jumping to that version. For now, if you ahve a small ZFS pool and want to add a single disk, your best plan of attack is to dump the pool to the array or another pool, delete and rebuild the pool with the new disk, then move the data back. for small cache pools that is still pretty easy.

I've been on U7 since Beta1 and only in the last couple of days has it slowed down, but not all the time, some containers will update at full speed but then one will slow down and take 15 minutes. So I don't think it's directly a U7 issue. I faintly remember having a similar issue way back maybe 5 years ago and it turned out to be a DNS issue.

Maybe some of these people should consider playing with your Simple Mover, rather than the full Mover Tuning, as it probably does what they need.

In that configuration, once a day at 8AM, it checks if the disk is >95% used, if yes it will move files older than 1 day, but only until it returns to the 95% threshold, so it wont move much unless the disk managed to get significantly higher than 95% in the time between scheduled runs. with a rule set like that I would be running hourly so the cache doesnt get a chance to overfill as it is checked more regularly. so if it got to 97% it would move the oldest files, ignoring anything less than 1day old, until it got back to 95% then it waits for the next schedule. I think the descriptions do need some updating, because the behaviour doesn’t quite match the wording. if you want to clear out ALL files more than 1 day old you need to set the clear down number to 0% so it moves everything older than 1 day.

if you disable the schedule it will only work if you manually click the move button, that was the same on the old versions too. There is no active file age checking going on, the script only runs when it is called and the only things that call it are the scheduler and the move now button? Perhaps you are looking for the way to run it without thresholds set? the current plugin does have a minimum of 5% instead of 0% which might be annoying in some niche cases where you want it to run on a very small collection of files but I cant see that being an issue?

can you run something like HTOP and see what is using the ram other than Frigate? I have 48gb of ram at the moment and even with 8gb of it being used by a ZFS ARC it's still under 50% with 30 container running. Unraid itself is only using 4GB or so.

the plugins first option is to disable the scheduler, which it does say "effectively disables the plugin" but you can still fire it off manually if the "Move Now button follows plug-in filters" is also selected. The way the config page of the plug-in was made unfortunately hides all the options if you select that, which I don’t think it should (there is a lot of re-wording and settings changes I would make to clean up the settings and descriptions), but it still works when you click "move now" or if you call the mover manually by copying the "/usr/local/sbin/mover start |& logger -t move &" command into an external script or some other trigger.

so what are you trying to do and what are you expecting to see? you have some shares that are cache only so no mover to be done there, and some that are cached but with a threshold at 95% that hasn’t been met, then you have some shares that dont use cache at all so again, no mover to be done. Also if you have the space for it, it is best not to try to run the mover on Appdata, keep that as Cache only for speed and to avoid the change of issues with your containers. it also cant move files that are in use, so it may over-fill regardless of your settings if a container is mis-configured.

uninstall that one and try the latest patched version manually by pasting this address into the manual plugin install page. you will probably need to reconfigure it, so keep in mind the default setting is test mode, which is a dry run where nothing is actually moved, so do that first to check the log output makes sense, then change that setting and let it run. You have shares with spaces in their names which are broken on the version you have, the fork i've linked to fixes that.

all covered very well in this thread but there are some bugs with shares with spaces in the name and some trouble with hardlinks.

the newer version has the ability to use a whitelist and pre/post scripts so with some tweaking that should get the job done for you.

There are updates in the works, but what version are you on? most people having an issue of "no moving at all" are on the much older version that has not had an update since 2023, if you have V 2024.09.05.0222 by Reynald, most functions do work on 7 with a few bugs being ironed out slowly.

might be time to just publish your fork, but only post a link here for manual installation until a confirmation from Reynald comes through, then if he decides to hand it over the link in the Community apps can be updated too. same for any other devs that would be willing to take it on longer term. I have manually made some of the changes to my plugin files on the system, but as soon as I reboot it's going to pull the unmodified version again.

pretty sure it is configured to update on boot, so it would pull the file from github and replace your modified .txz every time. So you could change the script in the .plg file to stop if from doing that, or even to pull from your own personal fork at boot. Or you could have a small script that goes in and replaces the age_mover file after the fact, which is probably safe but remember to remove it if the plugin is properly updated again.

That one is known issue that also affected the stock mover in V7 and we were talking about it a few pages back, it has now been patched with P1.0.0 but this plugin hasn’t had an update for a few months now and needs a similar patch applied manually, as you laid out in your other post. Thanks for posting the patch details though, very handy and I can confirm it works as I have tested it on my machine, though I don’t have any spaces in my share names. I've always had an aversion to spaces in any file or folder names because issues like this seemed to always crop up and break things.

you only have 16gb of ram, so what you are seeing is perfectly reasonable. Unraid will use as much ram as you throw at it, instead of your ram sitting unused all the time. The official Plex container uses very little ram at idle, maybe 200-300mb for a large server, it will spike up to a couple of gigs under heavy load but you have ~8gb free so that is perfectly fine. Definitely consider upgrading to 32gb in the future if you end up going over 80%-90% usage all the time though, you always want the system to have some free ram as it uses your "empty" ram for data caching in the background to speed things up.

in that situation I'd personally manually copy the entire contents of the cache over to a folder on the array, then delete the cache pool, configure a new one with the layout and format you need, assign the new correct disk, let it format, then copy the data back where it belongs and go from there. if the pool has the same name as the old one you wont have to do any re-configuring shares and mappings after that. I've done it that way a few times to convert into and then later expand a zfs pool (untill we get that feature built in), I know its not the best or fastest way but it works.

I think they wanted to get the plug-in out in a simplified state to push a CVE patch as soon as it was possible (and with so many people being so update and reboot averse, it was probably for the best), now that that is out of the way they are working on updating this (still optional) plug-in to add some more controls. I suspect some toggles for auto install or manual install will be added very quickly. Preferably with an option to auto install major CVEs but manually install minor bugfixes and patches.

if that is the case why not map the backup to /mnt/user/laptopA or something similar instead of directly to the cache? if "laptopA-documents" is a share configured in unraid to write to cache then move to the array, it will behave the way you expect and write to the SSD, then move later to the array, but the file location you hit never actually changes so the directory is always there. Also why not just configure one "backups" share then have subfolders within that for your devices? that keeps it all cleaner and lets you change settings on one master share instead of a bunch of separate shares for each device.

I had a very similar issue back in 6.12.x once and it turned out to be a quite literal log-jam.. I cleared all the syslog and nginx log (could have truncated them but I yolo'd it) and it came good.

That one is expected if you have mover tuning installed, the patch plugin explains that. the thread above is people having trouble installing patches on files that should be valid, but are still failing. What happens is the mover tuning plugin has renamed mover to mover.old and put its own script in place with the name 'mover' so that the scheduler calls the new script. The plugin wont patch it because it knows it's the wrong file, but doesn’t know why (I suspect they will update the patcher to look for mover.old as a failover and patch that). you could uninstall mover tuning, run the patch, then re-install (the correct version) of mover tuning or ignore it if you don’t need to run the old mover manually at all.

the little ones that mostly hide within the socket itself? I had nothing but issues with those for about 6 months straight, I went through 3 of them failure after failure until I went back to a basic USB2.0 stick (currently a Cruzer 'Facet') I've been on the same disk now for over 3 years.

The next kernel Unraid uses will almost certainly be 6.12 which still has ReiserFS built in (in an obsolete state, so unraid will let you read the disks but not make new ones). but after that, whatever kernel jump is made in the future will have zero ReiserFS support built in as it has been formally removed from the kernel in 6.13+ which was mainlined a few days ago. Unraid are unlikely to launch a stable version on a non-LTS kernel, so with LTS releases generally being the last release each year you can expect the next LTS kernel, without ReiserFS to be released at the end of 2025 and unraid would be running that version at some point after that. So you have about a year left. There are still ways to read ReiserFS after that point but it will be more of a pain at that point, so plan your transition over to XFS now.

longstanding bug that one. will probably be first to be looked at now that the dev is back.