I have been running into issues with my cache drive filling up and causing my VM to pause wile it waits for more space. I have checked several threads and I am yet to find an answer.

 

I have rebooted the server several times and I have used PuTTy to input command line inputs, to no effect.

 

I have been fighting the mover for some time now and I'm considering options to stop using the cache drive all together.

 

"Dec 13 22:50:25 Wheatly emhttp: shcmd (419): /usr/sbin/hdparm -y /dev/sdg &> /dev/null

Dec 13 22:50:29 Wheatly emhttp: shcmd (429): /usr/local/sbin/mover |& logger &

Dec 13 22:50:29 Wheatly root: mover started

Dec 13 22:50:29 Wheatly root: mover finished

Dec 13 22:53:32 Wheatly emhttp: shcmd (502): /usr/local/sbin/mover |& logger &

Dec 13 22:53:32 Wheatly root: mover started

Dec 13 22:53:32 Wheatly root: mover finished"

It might be worth posting your diagnostics (Tools->diagnostics) and mentioin8ng what shares seems to be causing you problems.  The syslog snippet you posted seems to suggest that according to your current settings there is nothing to move.

Here you go, the share that is giving my issues are Chris's files.

 

Could it be that the mover is not seeing the files?

syslog.txt

Y/u only provided the syslog.  The diagnostics requested includes a lot more than the syslog including configuration files so that we can check those at well.

my bad here is the full zip file

wheatly-diagnostics-20161213-2321.zip

Looking at the config files it looks as if the problem share is set with 'Use Cache: No'.  That setting will stop mover from moving files from cache to the array desks.  You need a setting of 'Yes' to get mover to do what you want. 

 

One question might be what caused such files to be placed on the cache desk in the first place?

Ok that fixed it, I didn't know that the mover just strait up skips shares that are marked as "use cache: no." I figured that it would check to make sure that there is no data on the cache drive from that share.

 

Good to know, thanks.

Ok that fixed it, I didn't know that the mover just strait up skips shares that are marked as "use cache: no." I figured that it would check to make sure that there is no data on the cache drive from that share.

 

Good to know thanks.

The cache and mover options have gotten WAY more complicated in the last year. It used to be that the share only had two options for cache, yes = writes destined for the share would be written to the cache first, and moved on schedule, and no = writes to the share go straight to the array drive.

 

Now that we have a couple more permutations, I think the cache configuration verbiage has become clumsy and not descriptive. My opinion is that the cache part of the configuration wording should be changed to something that better describes what is being configured, the mover script.

 

1. Move files from cache to array on schedule, new files write to cache - currently use cache disk "yes"

2. Move files from array to cache on schedule, new files write to cache - currently use cache disk "prefer"

3. Ignore files on cache, new files write to cache - currently use cache disk "only"

4. Ignore files on cache, new files write to array - currently use cache disk "no"

 

I think the configuration would be better served by 2 settings instead of combining the behaviour.

 

Move files = yes or no

New file destination = cache(future?) or array

 

One fly in the ointment is that the introduction of the "cache prefer" behaviour was specifically targeted to those who don't currently have a cache drive, but want to add one in the future. The very existence or not of a cache drive obviously changes the way things work.

OTOH you could say that the "prefer" option has made the "only" option obsolete and perhaps the latter's use ought to be deprecated. "Prefer" is more general in use, coping with both cache and non-cache scenarios. It automatically adjusts if a cache is added later. It also copes better if the cache becomes critically full, by allowing files destined for cache-prefer shares to be stored temporarily on the array and later moved onto the cache when space permits. I now use "prefer" in preference to "only" for my system and appdata shares.

And another thing to consider is if a file is written directly to a folder on the cache drive, that file will be in a user share (all top level folders on cache or array drives is a user share) that might be set to cache-no by default, and so would never be moved. As itimpi said

One question might be what caused such files to be placed on the cache desk in the first place?