Swarles

Yeah, a long time ago I added some functionality to this plugin and had the intention of probably taking it over once hugenbdd was planning on moving on. Eventually I decided I would rewrite the plugin from the ground up because the code was starting to become janky implementation slapped on top of more janky implementations and it was just getting too messy to even consider adding more advanced functionality. I progressed pretty far but graduated and got a full-time job as a robotics engineer and never touched it again...that was about a year ago. Turns out it's really hard to have spare time / effort and energy when you have a full-time job lol. I've got a lot of respect for the people that seem to have a million side projects and somehow balance them with a good work-life balance. I would like to pick up my development again because I had a lot of fun doing it, but I probably won't publish it because I can't commit to maintaining it and there are so many changes for me to go back and read. It's more of a class / object oriented approach so additional functionality can just be added in quite easily. I need to learn how to write tests for it because doing manual testing is so killer and wastes so much time, but having to write tests is also time consuming and not very motivating.

Is the error still appearing after the changes? The change will disappear after a reboot as well just FYI, can you verify the change is still there? Thank you

Mover tuning is essentially just a filter that sits between the mover being started and the mover actually moving files. So when the mover is called either through a schedule or manual run, if mover tuning is installed instead of just sending every file on the cache to the mover and having them all moved, the files will be filtered based on your settings and then sent to the original mover to move them. Mover tuning won't run outside of the mover being invoked. So if you have the schedule set to weekly, it'll only ever invoke the mover weekly (on Sunday in your case) and that's when it will filter files and move them. If you want the behaviour you mentioned where it moves files filtered on a more frequent schedule (set the main schedule to be more frequent) but then moves all files (ignoring tuning) on the sunday, you can use the option "Force move of all files on a schedule". Test mode works by going through all the steps of the mover without actually sending the files to be moved. If there are no files in a .list during test mode there won't be any in the non test mode. If the mover is not working for you, it is likely another issue, but the first thing to check would be all the steps in the FAQ#2. Based on your current settings, nothing will move if the cache your share is on is not above 70% capacity. Can you confirm it's using more than 70% currently?

Mover tuning settings are "disabled" for any Array->Cache moves. Effectively it just uses the default mover without filter and should move everything. It's disabled on the share level for this same reason, customising the settings wouldn't do anything. Regardless, it should still be moving all files associated with that share back on to the cache. The only thing I can suggest trying is disabling or removing mover tuning in the settings to see if it's the thing causing problems. Alternatively you could set the option "Move now button uses mover tuning settings:" to no and then invoke the mover on the main page. Otherwise I'll need some logs to help see what's happening. See FAQ item #3.

Yeah it's on line 370

Awesome! I haven't taken a look through the code but I'm sure this is a feature that many would find useful. Have you done much testing for it? I probably won't be able to take a look for another week or so. I'm not sure which version of age_mover you have taken this snippet from but the error is on line 370 showing in the latest release of the plugin. Yes this is correct. We don't sort the files at all currently. When the user selects the ctime or mtime option this is purely for the sake of determining the "Age" of the file.

You could write a script that runs before the mover to do this. Puts all the paths except the one you want to move into the skiplist file. Unraid doesn't update access time so unless your next cloud does, then no. Yes you can set most settings on a per share basis. It's AND.

You can specify folders that you want to keep on the cache at all times. It does nothing and behaves like the normal mover. Tuning array -> cache is probably a use case for less than 1% of people. But I do acknowledge some may want it. See above. Will only count on cache -> array moves. It won't ever ignore the "Array -> cache" or "cache -> array" ahre settings. Think of mover tuning as a filter that uses the built in mover. It will apply it's filter on "cache -> array" moves but it won't on the other. If you want everything on the cache until it fills up you can set it to "Array -> cache" and it will move stuff to the cache. If you add more files and they can't fit, they will go onto the Array. If you delete files off the Cache and space becomes available, they will move from the array to the cache. I think thats a bad setup though. Otherwise set it to "Cache -> array" think of some filters you want to use to keep only certain files or folders on the cache. Stuff that you think you will access constantly you can make exclude that folder in the mover tuning settings. The rest for example can just be moved. Maybe you only want the mover to move when you reach 50% capacity in the cache. Maybe you only want files that have been on the cache for 1 month already to be moved. Or both.

I think the "TOTALARRAYSIZE += : syntax error" is the same as the one identified back in Jan here. And the problem was identified here. This commit highlights the change but I don't think I ever shared it with you. Hopefully that solves it.

I think usually the "Some or all files unprotected" with the orange icon is related to not having redundancy. So on the array that could be no parity, or a compromised parity. On the cache that could mean you only have one cache drive or just no redundancy. Spaces can cause lots of issues in bash but for the most part the plugin tries to encompass everything in quotes so that they don't cause issues. It's possible that there is something unaccounted for however. If you get the errors again just drop another comment here and we can try figure it out. It's annoying but there's so many things it could be that it's difficult to know for sure what might be causing it.

Oh okay it looks like the folders it can't find are the following: /mnt/cache_ssd/Tech/pfSense/pfSense Backups/April 30 And /mnt/cache_ssd/Tech/pfSense2/pfSense Backups/April 30 This is a peculiar error as it's happening on the share mover not the main mover, the share mover does minimal processing, it basically just sends the share path to the unraid default mover. It seems like you figured out your problem was related to your HBA. Great work! I have no idea how you deduced that or why it would cause issues though. You can delete your diagnostics. If you want me to investigate or the issue hasn't gone let me know, I'll probably need you to confirm that that exact path does exist and if there is anything peculiar about its permissions or properties.

This may sound obvious but have you checked if the file or directory it is trying to move exists? It could be a number of things wrong. Is there any more info you can provide? See the FAQ on how to provide logs.

Unraid itself hasn't really had any big updates/changes recently that impact how the mover works. So it shouldn't be starting to break, but it does appear to be not working for some.

What are all your settings?

Hey sorry for the delay on this, I would very much like to get you up and running. Unfortunately I will need some logs from Mover Tuning which don't get saved with the diagnostics zip. If you follow the steps here in #1 to get the logs that should allow me to figure out exactly what is going wrong Don't worry about doing 3 runs, just the 1 should be fine.