hugenbdd

Members
  • Posts

    334
  • Joined

  • Last visited

1 Follower

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

hugenbdd's Achievements

Contributor

Contributor (5/14)

60

Reputation

  1. Change Disabled to "No", the way you have it now, it will never run mover unless hit the button. Also, turn logging on, then we can look at the syslog and see where it might be having issues. Might also want to turn on the test mode until we get it figured out. That way no actual files will be moved, but logs will be created. Sometimes text files have a weird end of line character (a ^) if it was created on a windows machine.
  2. No. The closest you can come with this plug-in is to play with your days old and % free to get close to the amount of space you want to keep filled up on the cache.
  3. No plug-in that I know that does that. but.... You can get pretty close with this plug-in. Set mover to run every hour or so, and set your percentage. It checks percentage on each run and then determines if it's over, to move files.
  4. Is this for the new 6.10 release or on 6.9.2 (Sorry a bit confused) ?
  5. 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
  6. 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.
  7. Fixed with new release. It now quotes the share name in the "Move All" code.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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?
  13. Thanks for this. I'll go back when I get some time in the next few weeks and try to reproduce.
  14. 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.
  15. 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.