Noticed today that my cache drive was filled up and mover is not working. 

Syslog shows the following when trying to use mover but doesn't do anything:

 

Usage: /usr/local/sbin/mover.old start [-e] <disk_name>
Apr 24 13:29:50 RAIDer move:        /usr/local/sbin/mover.old stop|status
Apr 24 13:29:50 RAIDer move:        <disk_name> must match pattern 'disk[0-9]*'

Attach Diagnostics ZIP to your NEXT post in this thread.

Please see attached

raider-diagnostics-20250424-1340.zip

Looks like the only share configured to be moved is

d--a                              shareUseCache="yes"     # Share exists on cache, disk1, disk2, disk3

 

appdata, domains, and system shares have files on cache and on the array, but aren't currently configured to use cache. We will work on that after we get room on cache for all files from those shares.

 

Is that user share named 'data'? Or what is its name?

 

 

Yes, the user share is named "data" and is where the majority of files are. 

What do you get from command line with this?

du -h -d 1 /mnt/cache

 

root@RAIDer:~# du -h -d 1 /mnt/cache
19G     /mnt/cache/domains
121M    /mnt/cache/system
4.8G    /mnt/cache/appdata
923G    /mnt/cache/data
947G    /mnt/cache

OK, so 'data' has 923G to be moved. That will take a while.

 

First thing, uninstall Mover Tuning plugin and leave it uninstalled until we get everything moved to where it belongs.

 

Then, go to MAIN - Array Operation, and click MOVE.

 

Wait for it to complete, then post new diagnostics.

Running now, log is showing files moving so progress is being made. 

While we are waiting for that. Why do you think you want Mover Tuning?

This was installed a few revisions back when I wanted it to be scheduled with certain exclusions, if it's native now there's no need to have it. 

Mover has always been native, at least as far back as Unraid V4.7, which is the first version I used back when I first joined the forum over 14 years ago. And built-in mover has always had scheduling. Default schedule is once-per-day in the middle of the night, and that is a pretty good default for most uses. Mover is intended for idle time. It is impossible to move from fast cache to slower array as fast as you can write to cache. Simple hardware limitation.

 

Mover Tuning is a fairly new plugin, seems to be in constant revision. Sometimes just reconsidering how to use cache is a better solution.

Do any of your Dockers or VMs write to 'data'?

The Dockers do, yes. I mostly have cache as "fast storage" which then is scheduled hourly to move the files over. Generally it's only a few GB at a time, only this large since I suppose it hasn't been running for a extended amount of time. 

The next thing we are going to do when we get room on cache is move your "default shares" to cache.

https://docs.unraid.net/unraid-os/manual/shares/user-shares/#default-shares

 

These shares should have all files on a fast pool (cache) with no files on the array, so Docker/VM performance isn't impacted by slower array reads and especially writes, and so array disks can spin down, since these files are always open.

 

Nothing can move open files. And it might be a good idea to go ahead and disable Docker/VM services so nothing further is written to cache until we are ready.

 

Go to Settings - Docker and disable. Go to Settings - VM Manager and disable. Leave them disabled until we have finished working with those "default shares".

Yep, disabled docker/VM already once I started the move job. 

My shares are set up in the following manner:

Those "default shares" will have to be reconfigured:

Primary:cache; Secondary:array; Mover action:array->cache

 

But, leave them as is until mover finishes moving 'data'.

Sure, will that configuration not fill up the Cache drive though? Or does it automatically shuffle files back to the Array once they're not in use?

That configuration will not move any of those shares to the array. And we don't want them on the array. It is possible that they would "overflow" to the array if cache gets below "Minimum Free".

 

But, the "default shares" shouldn't take up much of your cache. We can take a closer look at that when mover has finished with 'data'.

 

Finished - see attached for logs. 

raider-diagnostics-20250424-1957.zip

What do you get from command line with this? (may take a little while)

du -h -d 1 /mnt/user

 

So if all of appdata, domains, isos, system shares were on cache, they would only total 64G.

 

Set each of those shares to

7 hours ago, trurl said:

Primary:cache; Secondary:array; Mover action:array->cache

Run mover, wait for it to complete, post new diagnostics.

Sorry was away for the weekend. See attached for new diags. 

raider-diagnostics-20250428-1322.zip

Doesn't look like you did any of this:

On 4/24/2025 at 9:27 PM, trurl said:

Set each of those shares to

On 4/24/2025 at 2:19 PM, trurl said:

Primary:cache; Secondary:array; Mover action:array->cache

Run mover, wait for it to complete