Leaving mover on often, bad?

[SebTech33]

Is it bad to leave mover running often? i have a small cache drive and right now im moving a log of data around. yes i can turn off caching, but then it gets really slow. i thinking to set it to a bigger interval when im done. im moving about 1.6TB of data around on the server and my cache drive is only 256GB (im planning on upgrading this soon). i would not think its bad to leave it running often, but im not an expert on this. 

[trurl]

It is impossible to move from the faster cache to the slower array as fast as you can write to the faster cache no matter how often you run it. Running it more often might even make things worse. Mover is intended for idle time. Reconsider what you need to cache, or get a larger cache, or both.

 

4 minutes ago, SebTech33 said:

i thinking to set it to a bigger interval when im done.

Done with what? I don't recommend caching any of the initial data load because cache won't have enough capacity and will just get in the way. People often don't assign parity until after the initial data load so writes will go faster without parity updates.

 

Have you considered turbo write?

 

[SebTech33]

9 minutes ago, trurl said:

It is impossible to move from the faster cache to the slower array as fast as you can write to the faster cache no matter how often you run it. Running it more often might even make things worse. Mover is intended for idle time. Reconsider what you need to cache, or get a larger cache, or both.

 

Done with what? I don't recommend caching any of the initial data load because cache won't have enough capacity and will just get in the way. People often don't assign parity until after the initial data load so writes will go faster without parity updates.

 

Have you considered turbo write?

 

ok i understand a little. but if i understood turbo write correctly i need a parity drive (which i dont have currently, i dont have anything on it that i care much about. mostly dvd rips that i can rip again if something happens). im soon doing a big upgrade to my whole system so i can look at the possibility for adding a parity drive. i also use xfs file system, since brtfs corrupted so many of my files after a power outage. I'll read up some more on what to do with cache and mover. i have my shares set to prefer (appdata and domains) since the cache drive is so small and i dont want any problems. Many of the other shares i have it set to yes so it moves it to the array what mover runs. i very rarely add new files to if so i dont think thats a problem. Domains isn't really used for anything since i use a physical ssd for windows (128GB). thank you for your response. if you have any more ideas ill gladly take a look at it. im new to this, but im having fun learning.

[trurl]

10 hours ago, SebTech33 said:

i have my shares set to prefer (appdata and domains)

That's good, but the most important share to set prefer is system, where docker.img is normally kept. If you have any of it on the array it can be a multi-step process to get it moved since mover can't move open files.

 

If you need help with this post your diagnostics.

[SebTech33]

1 hour ago, trurl said:

That's good, but the most important share to set prefer is system, where docker.img is normally kept. If you have any of it on the array it can be a multi-step process to get it moved since mover can't move open files.

 

If you need help with this post your diagnostics.

I have it set to prefer cache now, i had some problems getting unraid to start but i got it fixed so sorry it took so long. before the vms started up it said everything was on the cache, but after it started it shows Cache: 42.9GB Disk 2: 33.3GB. is this normal or did it not move properly? i stopped both VM Manager and Docker and checked with krusader to see if it got moved properly by the mover and it did. dont know what happened after the vm started. appdata and domains says all the data is on the cache and nothing on the disks. ill put the diagnostics in if you need it.

sebtechnas-diagnostics-20200831-1609.zip

[trurl]

What do you get from the command line with these?

ls -lah /mnt/cache/system

ls -lah /mnt/disk2/system

 

[SebTech33]

3 minutes ago, trurl said:

What do you get from the command line with these?

ls -lah /mnt/cache/system

ls -lah /mnt/disk2/system

 

root@NAS:~# ls -lah /mnt/cache/system
total 0
drwxrwxrwx 4 nobody users 35 Dec  7  2019 ./
drwxrwxrwx 7 nobody users 80 Aug 31 15:50 ../
drwxrwxrwx 2 nobody users 24 Feb  2  2020 docker/
drwxrwxrwx 2 nobody users 25 Dec  7  2019 libvirt/

 

root@NAS:~# ls -lah /mnt/disk2/system
total 0
drwxrwxrwx  4 root   root   35 Aug 31 15:35 ./
drwxrwxrwx 11 nobody users 146 Aug 31 15:50 ../
drwxrwxrwx  2 root   root   24 Aug 31 15:35 docker/
drwxrwxrwx  2 root   root   25 Aug 31 15:35 libvirt/

[trurl]

It looks like the system share on disk2 has the current version of these things. Mover won't move duplicates, so you may need to get rid of those on cache before you can get them moved to cache. Or just rename the system folder on cache to system1 for example.

 

Do you know how to work with files directly on the disks?

[SebTech33]

51 minutes ago, trurl said:

It looks like the system share on disk2 has the current version of these things. Mover won't move duplicates, so you may need to get rid of those on cache before you can get them moved to cache. Or just rename the system folder on cache to system1 for example.

 

Do you know how to work with files directly on the disks?

i mostly use krusader to move around files on unraid and i can use that. the only weird thing is that there wasn't a system folder on the cache drive before and now there is.

also the files on the share is also bigger then the files on disk 2.

Edited August 31, 2020 by SebTech33
added more info

[trurl]

4 hours ago, SebTech33 said:

also the files on the share is also bigger then the files on disk 2.

Not exactly sure where you are looking to get that, but cache is part of user shares, so if there are files on cache for the user share then it is expected that the user share would be larger than just those files on disk2.

[trurl]

Anyway, I am just being cautious with blowing away any libvirt.img that might be on cache or disk2. It is fine to get rid of docker.img wherever it is because its contents are easily downloaded again. Since your system files on disk2 have newer timestamps than those on cache I assume these are the ones you want to keep. But I thought cache had precedence over array disks when there are duplicates, so I am not sure which is being used.

 

So what I am proposing is disabling VM Manager and Docker in Settings so these files won't be open and mover can move them.

 

Then, rename system folder on cache to system1 (instead of deleting) so it won't be a duplicate anymore and mover can move system from disk2 to cache.

 

Then, run mover so the system files on disk2 get moved to cache.

 

Then, enable VM Manager and Docker in Settings and see if your dockers and VMs are working OK. If so, it is safe to get rid of that system1 folder on cache since it isn't needed.

[SebTech33]

12 hours ago, trurl said:

Not exactly sure where you are looking to get that, but cache is part of user shares, so if there are files on cache for the user share then it is expected that the user share would be larger than just those files on disk2.

Here are some pictures of what i mean. the size is smaller on the disk than the files on cache. the dates on both files in both location is the same.

[SebTech33]

12 hours ago, trurl said:

Anyway, I am just being cautious with blowing away any libvirt.img that might be on cache or disk2. It is fine to get rid of docker.img wherever it is because its contents are easily downloaded again. Since your system files on disk2 have newer timestamps than those on cache I assume these are the ones you want to keep. But I thought cache had precedence over array disks when there are duplicates, so I am not sure which is being used.

Yeah i dont want to damage or corrupt my router setup now (i have backup of it so it not to bad if something was to happen,but not fun either way). The cache is using around 60GB and that was correct for the files before i moved them.

 

12 hours ago, trurl said:

So what I am proposing is disabling VM Manager and Docker in Settings so these files won't be open and mover can move them.

This is what i did before i moved "system" to the cache. there wasnt a system folder on it before.

 

12 hours ago, trurl said:

Then, rename system folder on cache to system1 (instead of deleting) so it won't be a duplicate anymore and mover can move system from disk2 to cache.

 

Then, run mover so the system files on disk2 get moved to cache.

if i do this again then it wont get the correct files if i understand this correct. it will move the smaller 1gb libvirt file to the cache and the 10gb one will be inactive. the docker img is the same size on both the cache and disk 2.

 

12 hours ago, trurl said:

Then, enable VM Manager and Docker in Settings and see if your dockers and VMs are working OK. If so, it is safe to get rid of that system1 folder on cache since it isn't needed.

in domain i see that the vdisk for pfsense is 1.8gb if that has something to do with the libvirt file. i would try that, but for now i need the pfsense vm to be active and cant afford it to be down for now. 

 

[SebTech33]

Did Turbo Write need to have a parity drive? i didn't get a confirmation on this, if so i won't enable it, but if it does not need it i can right?

[itimpi]

3 hours ago, SebTech33 said:

Did Turbo Write need to have a parity drive? i didn't get a confirmation on this, if so i won't enable it, but if it does not need it i can right?

Turbo write is not applicable if you do not have a parity drive on the array.

[trurl]

It is safe to delete docker.img as I said before. If the libvirt.img on cache is the correct one then delete (or just rename) the system share on disk2.

[SebTech33]

14 minutes ago, trurl said:

It is safe to delete docker.img as I said before. If the libvirt.img on cache is the correct one then delete (or just rename) the system share on disk2.

ok then ill try that

[SebTech33]

1 hour ago, itimpi said:

Turbo write is not applicable if you do not have a parity drive on the array.

ok, the i understood it right when i read about it. thanks

[trurl]

36 minutes ago, trurl said:

It is safe to delete docker.img

Just a little more info on this statement for future reference and anybody else that might be reading.

 

Since docker.img is just the executable code for your containers, that will be downloaded by installing your dockers again. The settings for each of your containers is in templates on flash. Using the Previous Apps feature on the Apps page will use those templates to reinstall your dockers exactly as they were. And the settings for each of the applications themselves is in their appdata.

 

So, it is always safe to delete docker.img and easy to get dockers going again just as before. In fact, deleting docker.img is the only way to fix it if it is corrupted, and perhaps even a good way to recreate it instead of moving it.

 

One other thing that might be required if you ever do this. If you create a custom docker network such as proxynet for letsencrypt (now SWAG) as seen in the Spaceinvader video, then you will have to recreate it after deleting docker.img. Best to do this before reinstalling any container that uses the custom network.