hugenbdd

Members
  • Posts

    331
  • Joined

  • Last visited

Everything posted by hugenbdd

  1. Is this for the new 6.10 release or on 6.9.2 (Sorry a bit confused) ?
  2. Few things. If you scroll back way in the thread we talk about a-time etc. I can't remember the specific's but the way unRAID is implemented it doesn't allow us to see the last "accessed" time of files. Would have made it very easy to move files over. If, someone comes up with code that provides a filelist, I could call that and send it to mover. i.e. off cache or onto cache. i.e. Essentially just using a cat filelist>mover
  3. Here's the line of code that is used to calculate. POOLPCTUSED=`df --output=pcent /mnt/$CACHEPOOLNAME | tail -n 1 | tr -d '%'` So if the df command is wrong, then so it the script. not much else I can go on. There is a scenario where later shares might not get moved as the percentage used drops, that I plan to fix after the new release of unRAID.
  4. Fixed with new release. It now quotes the share name in the "Move All" code.
  5. Supports all cache drives. Cycles through each share and it's respective cache drive. However, all settings are applied to the drives. i.e. no individual settings per drive.
  6. Yup, that looks like an error. It should have quotes around it. I'll review the code soon and try to get a bug fix out.
  7. I would suggest setting trying your setting and using the "test" option. Then review the logs to see if the files are moved, or are not moved based on what you want.
  8. Mostly a guess as Logs are what will pinpoint what is happening. Move All from cache is set very low. 5%... Could be that your cache is filling up above 5% and that means it's running the original mover command of running all files on the cache drives. I would suggest that be 70% or higher. It was originally meant for as a "fail safe" so that if someone is filling their cache up, it catches an almost full cache and just empties it over to the array.
  9. I believe this is because something still has the file locked. That log entry is from Unraids binary mover file. How long after the backup until mover kicks off. Could the backup still be writing the file from RAM or write cache to the disks and still has a lock on it?
  10. Thanks for this. I'll go back when I get some time in the next few weeks and try to reproduce.
  11. Mostly a replacement. It does in some circumstances call the original mover. There is a "test" mode, so that you can see what your selections will move, as long as logging is enabled. I have not tested/built with 6.10 yet as I'm extremely busy with work and my test box is not up and running.
  12. no, you can get 'close' to this functionality by setting mover to hourly and the percentage you want it moved at. Best to set your percentage a bit lower or get a larger cache drive to handle how much you can fill within an hour. Alternatively, you could setup a cron job that does this by parsing together some of the code in the plug-in and making your own bash script.
  13. That's odd. Looks like it should be enabling it. Is the entry "Forcing turbo write on" in your logs? As setting the write method is done in the mover.php that is run before the bash mover script. if ( $cfg['enableTurbo'] == "yes" ) { logger("Forcing turbo write on"); exec("/usr/local/sbin/mdcmd set md_write_method 1"); }
  14. Correct. Granted I need to go review the code which I haven't done just yet. But... Mover should be checking to see if parity check is started. If it's started then it will skip the move (depending on your settings.). It could have been in your case that mover started before parity started, even if just by a few milliseconds.
  15. I'll look into this. The settings look correct. Mover should not be running based on your settings.
  16. No, I may rewrite the plug-in for 6.10 after it's released to allow for a setting per share. But it is a lot of work to do this.
  17. Is this your first time opening the schedules page? i.e. nothing saved yet? There is a bug with some of the javascript I can't track down that may do this sometimes. I would say, make a small change somewhere, apply, and reload the page. Then see what happen.
  18. Thanks for the heads up. Will do!
  19. Hello I have taken over the Mover Tuning plugin from Squid a while back. I recently made a change that added the "Move Now" button to a Share page. I would like to extend this functionality to the Browse page (i.e. send a single directory to mover), however, I'm running into an issues. The Share page works by adding my own .page file to the plug-in. (Share.tuning.page) Entry to allow it to be visible. Menu="Share:2a" Title="Mover Tuning - Move All Files From Share" Tag="gear" However, when I try the same by crating a Browse.tuning.page it does not appear. Menu="Browse:2a" Title="Mover Tuning - Move All Files From Cache Share Directory" Tag="gear" In the little research I have done, it appears that the Share.page and Browse.page (Standard files in /usr/local/emhttp/webGUI) are of different types. Share.page is Type="xmenu" Browse.page is not an xmenu. Can anyone point me in the direction to add a button (and it's logic) to the Browse screen? Thanks
  20. Please enable logging. You may also want to play with this in test mode. Please post a few of the log entries with the "find" command also. One thing to note, is this is not event based, but time based. The trigger is the "scheduled time" you have set. at each time, it just checks the percentage of the cache. Then create the find command to send to the binary mover. That find command should have a time component to it if you select "days old".
  21. at the moment, no. The plug-in follows the same type of find command that the normal mover script uses. i.e. find <cache path> | /usr/local/sbin/move I do plan to update the plug-in to work off a file list, instead of the find command. i.e. loop through the file list, and possibly add a user selectable "wait" between files. You could try to set the two following items. Priority for mover process: <Low, or Very Low> Priority for disk I/O: <Low, or idle>
  22. For the time being it's just one level except for disk used %. Which can be set manually by editing the config file. (see 1-08-21 release notes) - age_mover bash script now check for global threshold percent or the a manual entry in the ca.mover.tuning.cfg file. (example: /boot/config/plugins/ca.mover.tuning cachetv="65") - "cachetv" being the name of the pool. - if using single digits leading zero required. (i.e. cachetv="01" for 1 percent) The way the plug-in script works, it loops through each share and checks against that shares cache settings/pool. If the setting is reached/surpassed it will run the find script on that share and send the files to the binary mover. The percentage used is calculated for each pool when each share is looped through it.
  23. I would suggest testing in the console. Start with.. find "/mnt/downloads/Media" -depth -type f -mtime +0 | grep -vFf '/mnt/user/appdata/mover_ignore.txt' Maybe, add 1 specific easy to name file. (No spaces) to see if it excludes it in the results. Once you get one file working, shortening the path in the exclude file. I'll also test tonight with my cache paths/files.
  24. You can try a few things from the console. /usr/local/sbin/mover stop Give it some time, and then see if the button comes back in the gui. If mover is already stopped, but for some reason the mover pid file still exists, you can delete it but you may be better off with a reboot. The mover button will stay greyed out if this file exists. /var/run/mover.pid cat /var/run/mover.pid Then try and see if it is still alive. ps -ef | grep <value from mover.pid file> as a last resort, or you know that mover is not running, you can delete the pid file. rm /var/run/mover.pid In my opinion prefer should only be used on appdata and shares that will stay very small. A media share should almost always never be set to prefer as it will move files off the ara filling up your cache drive.
  25. Sent you a message with some code that I'm reluctant to put in an updated release without some more testing.