hugenbdd

It's also possible that a share got changed from yes to no without mover running. Leaving them orphaned. I don't think its best to be built into the plug-in. Probably better to use something like Midnight Commander. However, I can still be convinced to look into it for a good reason.

noted, will include in the next update.

See the post a few up. Use the setting Ignore files listed inside of a text file: Then enter the path to your file containing the path to the directory you don't want moved. (i.e. must be /mnt/cache/ or your cache pool path, not the share path.)

Supports multiple pools. However, settings are applied to all pools.

Yup that’s the right find command. if you look further back in the thread someone posted a good explanation of how to use it. I’ll still review tomorrow.

I think you can do this. It has been a while since I programmed it and can't review the code right now. Will look at it tomorrow. However, you can play with this pretty easily. (without actually moving anything.) Create the text file, add the path you don't want moved. Then change two other settings. Move Now button follows plug-in filters: Yes Test Mode: Yes Hit the move now button and then review the sys log (upper right, 2nd most right button.) If it does what you want, change the test mode back to "no".

okay, that makes sense. You could write a custom script which loops through a list of files and sends each file to the mover to see if it solves the issue. Once the updates for the gui/mover progress come out, I should be able to accomplish something like this also. (i.e. a wait between files).

The way it's currently scripted, no. It pipe's in the find command to Unraid's binary mover. In the future? Possibly, there are some changes to Unraid that I'm waiting to be implemented that will track the mover's progress. Once that is implemented I may be able to do something like this. It's also possible a "tee" command could be used, but I don't think that will satisfy the "after moved" requirement you mentioned. Curios, what is the use case to run a script after every file?

The hourly schedule should be going off. Can you enable logging, post a screen shot of your settings and the mover entries in the syslog? For it to "automatically" move files based on percentage, you could setup a custom script that runs every minute and checks the size of the cache pool and then kicks off mover. you could take look at some of my code for examples of how to find the size.

With recent changes I think this can be implemented. Just will take some extra loops and creating a rather large file list. Then sending the file list to the mover instead of the individual find commands. Will keep track of this thread to see when it comes out in beta. But.. Depends on how it's implemented... Will check back once the feature is released.

Pretty much. I'm away from my server to check the code... but... if you have multiple cache pools, then it will also move those even if that other cache pool is not at 90% (Your setting). i.e. I call the original Mover bash script.

1.) Correct, the first thing mover does is check the percentage of the cache used. When it's run, if used space is >70% (your setting) it will then run through the rest of the filters and send the "find" string to the mover binary. 2.)Mover is only kicked off based on the schedule. Say you have Mover set to hourly, and the cache hit's 95% sometime in that hour, it won't move until the set schedule time. (i.e. hourly, or daily, etc)

New Release 2020.06.03 - Added size of all files from find string per share to test mode output. - Added "Ignore Hidden Files" option. This adds -not -path '/.' to the end of the find command. Requested by slimjim181 to help with video editing folders.

Looks like you are putting the directory into mover tuning. try the file. /tmp/user.scripts/tmpScripts/SyncRaid50/script

You are missing execute permissions on the file. chmod 775 on that file and it should help.

I'll try and look more at this tomorrow mornings. But in the meantime... Whats the permissions of the script and owner? i.e. ls -ltr /boot/config/plugins/user.scripts/scripts/SyncRaid50 Can you put a few "echo" statements in your script. i.e. beginning and ending?

The "mvlogger: No After Script to Run" is right at the end of my bash script. rm -f $PIDFILE [[ $LOGLEVEL -gt 0 ]] && echo "mover: finished" #Run mover after script if specified. if [ -z $AFTERSCRIPT ] ; then mvlogger "No After Script to Run." else if [ -f $AFTERSCRIPT ] ; then mvlogger "After script will be executed: $AFTERSCRIPT" eval "$AFTERSCRIPT" fi fi } <--- closes out the function and there isn't anything else to run... This does run in the controlling php script after the call to the bash script. if ( $cfg['enableTurbo'] == "yes" ) { logger("Restoring original turbo write mode"); exec("/usr/local/sbin/mdcmd set md_write_method {$vars['md_write_method']}"); } But I wouldn't think that would spin up your drives. It's also almost 30 seconds after the script has finished also. Is there a way to see what spins up drives in unraid? Other than the syslog entry?

I have heard that before. I'm not aware of any specific code to the plug-in that would spin up all drives. Three thoughts of what might be causing that. 1.) Cache-Prefer settings. This might be looking through all drives in order to move files over to the cache. 2.) Mover binary 3.) io priority settings. Can you run in "test mode"? Filter Settings to run in test mode. Move Now button follows plug-in filters: YES Test Mode: YES Then hit "move now". I just tried this, and it did not spin up my drives.

Can you post what your share config files are listed as? There is a mis-match somewhere between the config files (Case) and the share names. ls -ltr /boot/config/shares If that doesn't fix it can you post your debug file? original mover loops through the directory on the cache, where I have to loop through by config files.

upper right log icon/link or if in the console.... /var/log/syslog But like Simon F mentioned, make sure logging is enabled and you have it in test mode. (One of the last options in schedule page for the plug-in.)

Your data "should" be okay. If the array shutdown during a move, it's possible the file that the mover binary was in the process of sending to the array might be corrupt, but I doubt that all the files in your cache are corrupt. Latest release did fix this issue.

Kind of. You have to set the schedule to run every hour or daily. This plug-in does not monitor the size of the cache except when it is run on a schedule. (So hourly, daily, weekly, etc)

Yeah, I was tired of commenting out the line in the age_mover file while testing. Figured it would help people who have complicated filters. Side note, it will call the "before/after scripts". The test mode just won't send files to mover, it just executes the "custom find command".

New Release 2020.05.13 Fixed issue during a mover stop command, where it wasn't exiting correctly. Added Test mode. - Will run the find command outputting all the files that would have been sent to mover to the syslog if logging enabled. (Lets you see if your filter choices are correct.) Add "Move All" files in a share of cache-yes to the array if cache pool is above a certain % (Must be greater than "Only move at this threshold of used cache space:" Plug-in code will still run through each share after this function. However, it shouldn't move anything if a share path on cache is empty. Some big changes. I tested as best I could, please let me know if you run into issues.

I don't understand your question. Install the plug-in through CA community Apps, search for "Mover Tuner" and it should come up. To run scripts before and after, fill in the full path to the file you want run and make sure it has execution permissions.