[Feature Request] permanently stop (disable) dynamix mover

[AndrewT]

Is there any way from the webgui to disable the mover?

 

It looks like:

rm /boot/config/plugins/dynamix/mover.cron && update_cron 

will prevent the mover from running, I'm but just surprised the option "Disable" under Scheduler->Mover schedule is lacking considering right above it the "Parity Check" cron task does have the "Disable" option.

[ljm42]

Perhaps you could explain what you are trying to accomplish?  Fully disabling mover would completely break the share settings, it is unlikely that LT would ever offer an option to do that.

 

You can effectively disable mover by setting "use cache disk" to "only" for each user share.  This means that new files will be written to the cache drive and mover will not move them.  Existing files that are on the array (or that you manually put on the array) will not be moved either.  Files in either location are available via the user share. 

 

Of course, if you do this you have to be careful that your cache disk doesn't get full.

[BobPhoenix]

Perhaps you could explain what you are trying to accomplish?  Fully disabling mover would completely break the share settings, it is unlikely that LT would ever offer an option to do that.

It doesn't break the share settings they will work just fine with it disabled I did that for a long time.  The only thing disabling it would do is fill up the cache drive if you have your shares setup to use the cache drive - and you don't have to do that.  Once the cache drive is full unRAID would then write directly to the array for that share - assuming you setup minimum space free correctly anyway.

[ljm42]

It breaks the concept of the cache drive.  None of the settings make sense if you disable mover.  Support (explaining how it worked) would be a nightmare.

 

If all you want is for new files to go on the cache drive and stay there, then just set the share to cache only and you're done.  No need to disable mover at all.

[BobPhoenix]

It breaks the concept of the cache drive.  None of the settings make sense if you disable mover.  Support (explaining how it worked) would be a nightmare.

 

If all you want is for new files to go on the cache drive and stay there, then just set the share to cache only and you're done.  No need to disable mover at all.

Why do you say the settings don't make sense and breaks the concept of the cache drive?  It can still function the same as it always did you just have to move your files to the array yourself. I don't see how that doesn't make sense or even breaks the concept - but maybe I'm not understanding what you mean.

 

 

As to support I can see why limetech wouldn't want to support it since everything it is needed for can be achieved now without it - as far as I can tell.  But I can see a reason for disabling mover which I believe is done automatically now - parity checks.  When running a check I don't want any writes to the array happening.  Personally I wish in addition to disabling mover (like v6 does does now while parity is running - I believe) - I would like a parity check to make all user shares read only/cache only on writes while it is running.  In other words while a parity check is running nothing can write to an array drive directly - external or locally.  Writing to the cache drive would be allowed so if all shares used a cache drive it would still be possible to write to unRAID if needed - until it was full anyway.

 

 

When I did this (unRAID v5) I renamed the mover script directly because I wasn't using Dynamix at the time.  So no cron entry to rename.  But everything I wanted by disabling the mover is now taken care of in unRAID v6 - at least I think so anyway - except the read only user shares.

[Squid]

It breaks the concept of the cache drive.  None of the settings make sense if you disable mover.  Support (explaining how it worked) would be a nightmare.

 

If all you want is for new files to go on the cache drive and stay there, then just set the share to cache only and you're done.  No need to disable mover at all.

Why do you say the settings don't make sense and breaks the concept of the cache drive?  It can still function the same as it always did you just have to move your files to the array yourself. I don't see how that doesn't make sense or even breaks the concept - but maybe I'm not understanding what you mean.

 

 

As to support I can see why limetech wouldn't want to support it since everything it is needed for can be achieved now without it - as far as I can tell.  But I can see a reason for disabling mover which I believe is done automatically now - parity checks.  When running a check I don't want any writes to the array happening.  Personally I wish in addition to disabling mover (like v6 does does now while parity is running - I believe) - I would like a parity check to make all user shares read only/cache only on writes while it is running.  In other words while a parity check is running nothing can write to an array drive directly - external or locally.  Writing to the cache drive would be allowed so if all shares used a cache drive it would still be possible to write to unRAID if needed - until it was full anyway.

 

 

When I did this (unRAID v5) I renamed the mover script directly because I wasn't using Dynamix at the time.  So no cron entry to rename.  But everything I wanted by disabling the mover is now taken care of in unRAID v6 - at least I think so anyway - except the read only user shares.

Here's how you can do it through the user.scripts plugin.

 

You have to edit a file on the flash drive to permanently disable mover, and then set the script to run say monthly, use dynamix Scheduler to set the monthly schedule to a start time that is at least a couple of minutes AFTER a parity check is set to begin.

 

http://lime-technology.com/forum/index.php?topic=50416.msg487850#msg487850

[ljm42]

But I can see a reason for disabling mover...  parity checks.  When running a check I don't want any writes to the array happening

 

Yep, love the idea of temporarily disabling mover doing parity checks.  Agree it should be automatic though, not with a switch in the gui.

 

Here's how you can do it through the user.scripts plugin.

 

That is really cool   And because you are still moving files, you aren't changing the definitions of the "use cache disk" share setting.

 

 

[Squid]

But I can see a reason for disabling mover...  parity checks.  When running a check I don't want any writes to the array happening

 

Yep, love the idea of temporarily disabling mover doing parity checks.  Agree it should be automatic though, not with a switch in the gui.

 

Here's how you can do it through the user.scripts plugin.

 

That is really cool   And because you are still moving files, you aren't changing the definitions of the "use cache disk" share setting.

Made a mistake though  to work right it has to be set daily not monthly  still with a start time set after a parity check runs. 

 

Sent from my SM-T560NU using Tapatalk

 

 

[BobPhoenix]

Here's how you can do it through the user.scripts plugin.

 

You have to edit a file on the flash drive to permanently disable mover, and then set the script to run say monthly, use dynamix Scheduler to set the monthly schedule to a start time that is at least a couple of minutes AFTER a parity check is set to begin.

 

http://lime-technology.com/forum/index.php?topic=50416.msg487850#msg487850

Knew I'd seen it somewhere.  Thought it was built in.  Glad it is available some how.  Since the only shares on my cache drives are "cache only" I don't need it personally but glad it is available.

[Squid]

Here's how you can do it through the user.scripts plugin.

 

You have to edit a file on the flash drive to permanently disable mover, and then set the script to run say monthly, use dynamix Scheduler to set the monthly schedule to a start time that is at least a couple of minutes AFTER a parity check is set to begin.

 

http://lime-technology.com/forum/index.php?topic=50416.msg487850#msg487850

Knew I'd seen it somewhere.  Thought it was built in.  Glad it is available some how.  Since the only shares on my cache drives are "cache only" I don't need it personally but glad it is available.

Its still a hack taking advantage of the fact that dynamix isn't doing any error checking on the cron entry.  No guarantees it will work on any future versions of dynamix.  And changing global share settings is going to undo the hack.

[BobPhoenix]

Here's how you can do it through the user.scripts plugin.

 

You have to edit a file on the flash drive to permanently disable mover, and then set the script to run say monthly, use dynamix Scheduler to set the monthly schedule to a start time that is at least a couple of minutes AFTER a parity check is set to begin.

 

http://lime-technology.com/forum/index.php?topic=50416.msg487850#msg487850

Knew I'd seen it somewhere.  Thought it was built in.  Glad it is available some how.  Since the only shares on my cache drives are "cache only" I don't need it personally but glad it is available.

Its still a hack taking advantage of the fact that dynamix isn't doing any error checking on the cron entry.  No guarantees it will work on any future versions of dynamix.  And changing global share settings is going to undo the hack.

Which is one reason I was renaming the mover script itself on v5.  I wanted it permentally disabled.  I don't use a cache drive with v6 as a cache drive it's more of an apps drive so don't really care now.

[AndrewT]

Its still a hack taking advantage of the fact that dynamix isn't doing any error checking on the cron entry.  No guarantees it will work on any future versions of dynamix.  And changing global share settings is going to undo the hack.

Thanks for the referencing link. As you warn, it sure looks like a hack and is likely to be undone at some point.

 

These responses made me think I'm the weird one not wanting the cache disk to have its content copied onto the array. As BobPhoenix mentioned, when I used unraid v5 I just used the cache disk to store everything to do with apps (configs, temp downloads, etc) and I back it up manually with an rsync before making big changes to a subdir within a share on my array. The one time I trusted it to transfer a bunch of documentaries I lost them, so I'm still a bit scared of the 'mover' function.

 

I dug into the mover function for unraid 6 and it's a very well documented bash script written (credit to limetech): `less -S /usr/local/sbin/move` to view. The commenting is so good it reminded me of a trick I've forgotten about in moving from unraid 5 to 6, which is that **hidden paths are ignored by the mover!**

 

Also, for limetech, there's a typo on L35 in the commenting:  `sed -i 's/arary/array/1' /usr/local/sbin/move`

 

So, I think this might be the best approach instead of hacking a mover disabling altogether is to just hide the handful of paths I don't want mover to touch. Please suggest otherwise if any of you disagree.

 

Example fix:

mv /mnt/cache/appdata /mnt/cache/.appdata

[BobPhoenix]

So, I think this might be the best approach instead of hacking a mover disabling altogether is to just hide the handful of paths I don't want mover to touch. Please suggest otherwise if any of you disagree.

 

Example fix:

mv /mnt/cache/appdata /mnt/cache/.appdata

Mover is not suppose to move any folder that is set to "Cache Only".  So you should be able to set it up that way rather than making your folders dot folders. 

 

 

For me it wasn't so much a specific folder but of a time. I want to do it myself rather then automatically.  I move files in batches to my servers directly to the disks so I don't need mover but I can see that someone downloading files every day would need it.  For similar reasons I don't use CA's automatic backup feature for my docker.  The software inside the docker needs to control when the backup happens.  I could be recordings something off of Satellite or OTA at all hours of the day and the automatic backup feature shuts down the docker to do the backup as far as I know.  If snapshotting was implemented for my btrfs cache pool and CA used that and didn't shut down the docker then I would use that instantly.  So if someone has a script to do that I would be interested in it.

[trurl]

As mentioned, what you are trying to accomplish is easily handled by setting your appdata share to Use cache disk: Only. This feature has been around for a while and is the standard way to do what you are trying to do.

 

I never cache user share writes, but I have a number of cache-only shares, including appdata.