so I added a couple of SSD's for cache, and I've set appdata, domains and system to only be on the cache. 

 

I made sure no containers or VM's were running, ran the mover and everything moved except system.  I can't get the sucker to move to cache.  Is there a trick to this?  I've tried prefer cache and cache only, neither seem to have any effect on the system share.  Something must be using it, I just don't know what.

Edited June 12, 20197 yr by Abzstrak

6 minutes ago, Abzstrak said:

so I added a couple of SSD's for cache, and I've set appdata, domains and system to only be on the cache. 

 

I made sure no containers or VM's were running, ran the mover and everything moved except system.  I can't get the sucker to move to cache.  Is there a trick to this?  I've tried prefer cache and cache only, neither seem to have any effect on the system share.  Something must be using it, I just don't know what.

Turning on the help in the GUI should make it clear why this happened.  Basically 'Only' was the wrong setting to use - you need to use 'Prefer' to get the behaviour you want.

5 minutes ago, itimpi said:

Turning on the help in the GUI should make it clear why this happened.  Basically 'Only' was the wrong setting to use - you need to use 'Prefer' to get the behaviour you want.

As I mentioned, I've tried cache only and prefer both, neither move anything from the system share to cache.

 

I have 6 spinners, 3 of which wont sleep and I think it's because system wont move anything to cache.  system only exists on one drive, but I have double parity so half my drives wont spin down.  Moving things to the cache pool seems the obvious answer, I mean... I can rsync it manually, but that seems like a bad idea.

Edited June 11, 20197 yr by Abzstrak

1 minute ago, Abzstrak said:

As I mentioned, I've tried cache only and prefer both, neither move anything from the system share to cache.

Did you make sure that the docker and VM services were stopped (rather than simply no containers or VMs running)?  If the services were running they would have files open that mover will therefore not move.

6 minutes ago, Abzstrak said:

system only exists on one drive, but I have double parity so half my drives wont spin down.

Huh? That doesn't make any sense.

 

Also, as itimpi said, make sure docker and vm services are set to no in settings. If there is still a docker and VMS tab on the webGUI, they aren't off yet.

1 minute ago, jonathanm said:

Huh? That doesn't make any sense.

 

Also, as itimpi said, make sure docker and vm services are set to no in settings. If there is still a docker and VMS tab on the webGUI, they aren't off yet.

6 drives, two of which are parity.  Writing to one of the data drives causes the two paritys to also spin up... therefore 3 of 6 drives spin (half my drives)

 

No I didn't set docker and vm's to no, I just shut them all down.  Sry, still new to unraid.  I'll try that.  Thanks guys.

9 minutes ago, Abzstrak said:

drives, two of which are parity.  Writing to one of the data drives causes the two paritys to also spin up... therefore 3 of 6 drives spin (half my drives)

Any time you write to any array disk both parity drives will also be written to, and as you say with your configuration that is half your drives.   With so few drives I would not think having two parity drives is cost effective.  Unless you plan to add more drives later you might be better off using the parity2 drive as either an additional data disk, or as a disk to be used for backups.

4 hours ago, itimpi said:

Any time you write to any array disk both parity drives will also be written to, and as you say with your configuration that is half your drives.   With so few drives I would not think having two parity drives is cost effective.  Unless you plan to add more drives later you might be better off using the parity2 drive as either an additional data disk, or as a disk to be used for backups.

Yeah, with 16TB I prefer double parity.  All these drives are older, makes me feel better even though I do have backups.

ok, I put no in both vm manager and docker... went in and hit move now, and nothing... just sits there and didnt move or do anything.  super annoying.

 

I tried stopping the array and starting it back up, nope.  I went ahead and bounced the box, same thing... cant get system to move.  I have to assume mover doesn't want to move it for some valid reason

 

From the /var/log/syslog:

Jun 11 13:04:15 Athena emhttpd: shcmd (85): /usr/local/sbin/mover |& logger &
Jun 11 13:04:15 Athena root: mover: started
Jun 11 13:04:16 Athena root: mover: finished

 

Looks like it ran for 2 seconds and stopped... Is there somewhere I can turn up the verbosity of the logs?

 

After the reboot, fix common problems plugin ran  and is giving me this warning:

Share system set to cache-only, but files / folders exist on the array

 

no kidding... that's what I'm trying to solve, lol

 

 

Can I make sure that docker and vm's aren't running and just move that data to the cache manually?

Edited June 11, 20197 yr by Abzstrak

I ran into that issue when I first added my drive, and ultimately just moved everything over using terminal commands. Kinda dangerous if you don't know what you're doing, but sometimes you just gotta get a bigger hammer...

You could also try running docker safe permissions before running the mover. It could be a permissions issue, maybe?

26 minutes ago, Abzstrak said:

ok, I put no in both vm manager and docker... went in and hit move now, and nothing... just sits there and didnt move or do anything.  super annoying.

 

I tried stopping the array and starting it back up, nope.  I went ahead and bounced the box, same thing... cant get system to move.  I have to assume mover doesn't want to move it for some valid reason

 

From the /var/log/syslog:

Jun 11 13:04:15 Athena emhttpd: shcmd (85): /usr/local/sbin/mover |& logger &
Jun 11 13:04:15 Athena root: mover: started
Jun 11 13:04:16 Athena root: mover: finished

 

Looks like it ran for 2 seconds and stopped... Is there somewhere I can turn up the verbosity of the logs?

 

After the reboot, fix common problems plugin ran  and is giving me this warning:

Share system set to cache-only, but files / folders exist on the array

 

no kidding... that's what I'm trying to solve, lol

 

 

Can I make sure that docker and vm's aren't running and just move that data to the cache manually?

Did you make sure the share was set Use Cache=Prefer?

 

You might want to enable mover logging to see if that give any more information.

Edited June 11, 20197 yr by itimpi

8 hours ago, itimpi said:

Did you make sure the share was set Use Cache=Prefer?

 

You might want to enable mover logging to see if that give any more information.

no I still had them set to cache only.  Finally got some time to play with it again, I set it to prefer and now its moving...  I guess the mover doesn't work on cache only settings?

7 minutes ago, Abzstrak said:

no I still had them set to cache only.  Finally got some time to play with it again, I set it to prefer and now its moving...  I guess the mover doesn't work on cache only settings?

Yes - you need Use Cache = Prefer.    The Setting affects:

• where new files get created
• what action (if any) mover should take

The GUI built-in Help makes it clear how each of the settings affect the above two points.   They are not necessarily what many new users expect from the text of the possible values.  

Edited June 12, 20197 yr by itimpi

33 minutes ago, itimpi said:

Yes - you need Use Cache = Prefer.    The Setting affects:

• where new files get created
• what action (if any) mover should take

The GUI built-in Help makes it clear how each of the settings affect the above two points.   They are not necessarily what many new users expect from the text of the possible values.  

yeah, I read the help, the weird thing was if I set it to cache only then the mover seemingly never tries to move it from the array to the cache pool, which I would expect it to.

My drives are all spinning down now the way I wanted, awesome.  I mounted my movies and series folders as read only into docker, and now the parity's don't spin up;  I can play a show out of readonly folder and it only spins up the data drive   I only gave RW on the OTA recordings, as I want plex to be able to delete from there. 

 

Thanks for your help.

Edited June 12, 20197 yr by Abzstrak

8 hours ago, Abzstrak said:

yeah, I read the help, the weird thing was if I set it to cache only then the mover seemingly never tries to move it from the array to the cache pool, which I would expect it to.

Here is what the help says now. The only settings that mention mover are yes and prefer.

Quote

Specify whether new files and directories written on the share can be written onto the Cache disk/pool if present.

 

No prohibits new files and subdirectories from being written onto the Cache disk/pool.

 

Yes indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool. If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array. When the mover is invoked, files and subdirectories are transferred off the Cache disk/pool and onto the array.

 

Only indicates that all new files and subdirectories must be writen to the Cache disk/pool. If there is insufficient free space on the Cache disk/pool, create operations will fail with out of space status.

 

Prefer indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool. If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array. When the mover is invoked, files and subdirectories are transferred off the array and onto Cache disk/pool.

How should it be worded so as to be more clear?

11 minutes ago, jonathanm said:

Here is what the help says now. The only settings that mention mover are yes and prefer.

How should it be worded so as to be more clear?

I think the No and Only options should specifically state that mover will take to action.   It can be inferred from the current wording but could be more explicit.   in the "No" case it should perhaps be emphasised that if files that logically belong to a share end up on the cache (which can happen with downloader type apps) they will not be moved to the array

Edited June 12, 20197 yr by itimpi

2 minutes ago, itimpi said:

I think the No and Only options should specifically state that mover will take to action.   It can be inferred from the current wording but could be more explicit.

@bonienl should easily be able to get that changed going forward.

Is there any benefit once your data is moved to the cache drive to change the setting from prefer to only? 

With prefer if the cache drive gets full, then any new files in appdata will get written to the array and then when space frees up they'll get moved to the cache drive.  With only the write will fail if the drive is full.

On 6/11/2019 at 11:18 AM, wrenchmonkey said:

I ran into that issue when I first added my drive, and ultimately just moved everything over using terminal commands. Kinda dangerous if you don't know what you're doing, but sometimes you just gotta get a bigger hammer...

You could also try running docker safe permissions before running the mover. It could be a permissions issue, maybe?

1. I went to settings -> docker and set enable docker to "no".  that caused processes hanging on to /mnt/disk*/system/* to exit - probably the loopback mount of docker.img onto /var/lib/docker.

2. Then ran mover and that copied files into docker.img and libvirt.img into /mnt/cache. 

3. Then set enable docker to "yes" and apply.

Then spin down disks and confirm they don't spin up again.  You can verify what files are hitting the disk with 'lsof | grep /mnt/disk'. 

 

In my case i still had a grafana/influxdb container accessing files in /mnt/disk*/appdata because i forgot to re-set "cache: prefer" for that, so I had to take a further action of stopping that container, running move again until it was complete and starting container back up.  A subsequent 'lsof' confirmed no /mnt/disk references and exclusively /mnt/cache/appdata instead.