Swarles

Share override settings take higher priority than the global mover tuning settings. If you disable mover tuning it will also disable the share override settings. Leave everything default in the global "scheduler settings" and the mover will behave has default. Then you can make changes in the individual shares. If you want a share to not use the mover at all, disable the mover in that shares configuration

The short answer is to schedule the mover to run more frequently. If you have a threshold setup it won't do any moves unless that threshold has been reached.

Depending on how many files you have on your array at the moment you could just set it to move from array->cache run the mover then set it back to cache->array and make it use your settings. I'd you have lots of files that'll either take a long time, waste write cycles, or be impossible. So what you should do then is come up with your own find string to find the files you want to move from the array to the cache, eg. find /mnt/disk*/ShareName -depth -size -50M That will search all of the disks that contain the relevant share and find files that are less than (and equal to I think) 50MB. Use ChatGPT to fine tune it to the exact parameters you want if you're not familiar with the find command. It will print out a list of files and folders it finds. Then if you want to manually move them you can do that, or you can ask ChatGPT how to write your own command with eg rsync to do it, or you can temporarily set the mover for that share to array->cache (DON'T RUN THE MOVER NOW) you will then manually invoke the mover by adding the following to end of your find string. | /usr/local/sbin/move That will pipe all the file paths the find string finds into the built in mover which will then see the share is set to move from the array to the cache and it will do the moves for you Don't forget to change your share mover setting back to what you want.

Yeah so at the moment that's not possible with the raw plugin and I totally understand the desire for it. Infact at the moment, there is no mover tuning settings for array->cache moves at all. I have been working on creating a new plugin from the ground up which will bring all the tuning settings to array->cache moves as well even though it probably won't be used by 90% of people. Unfortunately because the mover only really moves stuff one way depending on how the share is configured, what you desire is not easily achievable by manipulating the built in mover. So there may be circumstances where files on the array that your tuning settings would normally keep on the cache will remain on the array. This would be likely to occur if you set up mover tuning after having already established your server file system, or changing the mover tuning settings considerably. What I will think about though, is creating a button that will extract files on the destination drive that match the source drives mover tuning settings (but the opposite), for the purpose of ensuring all files on that share are following the tuned settings. That way you would only need to run it once after making changes to mover tuning. I think this would address your feature request In saying this, the plugin is still a fair way off and this feature will be lower down on my priority list.

Unfortunately your exact requirements are not currently supported. The primary issue is that in point #3 the threshold will take precedence, so if the threshold is not exceeded, files that are older than X days will not be moved. They will only be moved if the threshold has been exceeded AND they are older than X days. Furthermore, the threshold operates on a pool level not a share level, as a share typically does not have a set maximum capacity. So the threshold takes into account the usage of all shares on that pool. You might be able to implement your desired logic by slightly modifying the before script Terebi posted above. Otherwise I recommend setting the threshold to a value that is suitable for all your shares. And then understand that it will only ever move the shares if that threshold is exceeded and then if it is going to move files it will use all your other settings. I'm remaking mover tuning from the ground up and it will support your desired functionality, but it is quite a ways off at the moment.

Interesting, so are you having issues running Mover Tuning entirely? What version of unraid are you using?

In that case you should be able to echo the list of file paths and pipe them into "/usr/local/sbin/move -d".

Yeah unfortunately the way the individual share mover script is implemented it doesn’t use the mover tuning settings. It honestly wouldn’t be the hardest thing to implement so I might do it, but I’m also working on revamping the plug-in from the ground up so that’s where my limited time is being spent at the moment. For now the easiest thing you can do if you want to use the tuning settings but move only 1 share (or a few), would be to put the path for all the other shares in the skip files list. eg. /mnt/cache1/share1 /mnt/cache1/share2 /mnt/cache2/backups etc This will work exactly as expected, albeit quite inefficient as it will still loop through each share but just find no files. Honestly I’m not really sure how the built in mover handles hard-links, but I can tell you that when the mover tuning plugin detects a hard-link in the list of files that should be moved, it sends the entire list of files as a single group to the mover (sbin/move). Otherwise it sends only 1 file path at a time, I didn’t implement this and so I am not sure if this a requirement or not.

See #3 on the FAQ.

I think it would be possible but It's not something I would want to implement in the current mover tuning code base. I am currently in the process of building the mover tuning plugin from the ground up fully in php, using OOP practices and I'll think about the best way to implement evaluating a threshold on a per dataset basis. I'm not sure if I would ship it in the first release but the idea of migrating to OOP would be to make implementing stuff like this easier. For the time being it will remain a whole pool basis unless someone else wants to implement it. In light of that which one do you think would be better to use going forward? zpool get -o value capacity OR df --output=pcent That's weird, can you confirm if that file appears if you perform the following: find '/mnt/cache/movies' -depth -not -path '*/\.*' If not, you might need to confirm what find string is being used in the logs. I couldn't find any code relating to destroying datasets which leads me to believe this is a feature baked into the built in mover. I could possibly add a check to not send datasets to the mover when that setting is enabled. This will definitely be an option when I finish building the new mover tuning plugin.

See item #3 on the FAQ. Make sure the file is readable, double check the file is actually in that location, it's likely that the mover could have moved it after the first run. If it still isn't working, you'll have to provide the latest ".logs" files for me to see what is going on. See item #1 on the FAQ for providing logs

The way it's done on the share page is an onclick event that calls the following: $.post("/plugins/ca.mover.tuning/moveShareNow.php?Share='<?echo $shareName?>'"); The "moveShareNow.php" script executes the following: exec("/usr/local/emhttp/plugins/ca.mover.tuning/share_mover {$shareName} >> /var/log/syslog &", $output, $retval); You can definitely call that script from cmd and just provide the share name as an argument: bash /usr/local/emhttp/plugins/ca.mover.tuning/share_mover 'shareName' NOTE: The share_mover script in the current plugin does not consider the mover tuning settings and will move everything off that share

FAQ - Frequently Asked Questions I'm putting these here for some of the common problems, and will try to update it as more questions/issues come along. How do I enable logs / provide logs? Mover wont run after installing Mover Tunning? Mover isn't ignoring files or folders? Issue Reporting Template

Oh okay during boot makes sense, I have found the issue. line 113 of "ca.mover.tuning.plg" if [[ ! -f /usr/local/bin/mover.old ]]; then mv /usr/local/bin/mover /usr/local/bin/mover.old; fi I uninstalled the plugin and rebooted and it would appear that unraid does not initialise a "mover" file in "/usr/local/bin/mover" (on 6.12.8 at least). "move" is located in "bin" and "mover" is located in "sbin". I don't know enough about unraid to know why this is the case or what the configuration is in older OS. It's probably important for people on older OS. I can confirm that this is not an issue to worry about though. We could change it so it checks if "mover" exists rather than if "mover.old" doesn't exist, thoughts @hugenbdd? If it is really bothering anyone, for the time being you can remove the line in "/boot/config/plugins/ca.mover.tuning.plg" or suppress its output.

@2TC @modem7 @BazzT92 @wgstarks Hmm I can't seem to recreate this issue after having updated to 6.12.8. Would someone with the issue be able to clarify the following: Does this error message happen whenever Mover is trying to start or during boot of the machine? Does this error message happen during scheduled mover or when using "Move" button on main page? (With "Move now button uses mover tuning" enabled.) Can you verify that the file exists manually? ls -l /usr/local/bin/mover Output: -rwxr-xr-x 1 root root 161 Feb 25 11:05 /usr/local/bin/mover* Are the permissions the same as above? Check the cron entry and verify cat /etc/cron.d/root Output: # Generated mover schedule: 40 3 * * * /usr/local/sbin/mover |& logger Check if your output is the same. If you verified both steps 3 and 4 to be true, try uninstalling the plugin, reboot, and reinstall. You can backup your settings with the following: cp -r /boot/config/plugins/ca.mover.tuning /boot/config/ca.mover.tuning.backup Once you have reinstalled, you can restore your settings with: mv -f /boot/config/ca.mover.tuning.backup /boot/config/plugins/ Let me know if issue persists.