recreate docker.img - and possibly other stuff

[kcossabo]

Background
Working through a number of bad disk issues, and a system that was rebuilt 20+ times in the last 4 months. 

The latest was a Seagate SMR disk that went bad (2 months old). Console reported 
 

kernel: ata3.00: failed command: READ FPDMA QUEUED

found the drive, removed it, then tried to use

> Tools > New Config
 

to reset the array, but, kept getting this 

 

nginx: 2024/03/26 18:49:02 [error] 5208#5208: *4210 connect() to unix:/var/run/emhttpd.socket failed (11: Resource temporarily unavailable) while connecting to upstream, client: 10.10.10.99, server: , request: "POST /update.htm HTTP/1.1", upstream: "http://unix:/var/run/emhttpd.socket:/update.htm", host: "10.10.10.5", referrer: "http://10.10.10.5/Tools/NewConfig"

 

So I found a post that said you could reset the config by removing everything but the key and go from /boot/config  

 

Did this rebuilding the server. 

Now there is no /mnt/user/system - thus no /mnt/user/system/docker/docker.img

 

find /mnt -name libvirt.img

 

returns nothing.

Question:

how do I recreate the /mnt/user/system correctly (I know I can build the share) so that it has all the correct files, in particular docker.img

Thank You 

[trurl]

https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file

 

https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications

[kcossabo]

I assume there is nothing else in a normal /usr/system directory?

[trurl]

/usr is a folder in the OS, which is in RAM.

 

The user shares are at /mnt/user.

 

The system user share only has docker.img and libvirt.img in a default setup. This is actually specified in Docker and VM Manager settings and so is under user control.

 

And of course there is nothing to prevent users from putting other things in the system share so no way for me to know whether you had anything else in there or not.

 

appdata, domains, and system user shares by default are setup to live on cache pool, so Dockers/VMs will perform better and so array disks can spin down since these files are always open. This is also under user control since you can change this and specify other shares or disks for these, in Docker and VM Manager settings, and even for specific containers or VMs.

 

Best if you don't enable Docker or VM Manager until you have cache or other fast pool setup, or these will get created on the array instead.

[kcossabo]

5 hours ago, trurl said:

Best if you don't enable Docker or VM Manager until you have cache or other fast pool setup, or these will get created on the array instead.

Thank You so much.

I did set it up on the main array, now changed it to the cache, and invoked the mover, that is not a quick action.

When I spun up the docker containers, while the system was on the array, the network performance dropped. When I stopped Docker to move the share, the network recovered.

I have a few rsync's running moving data back to this server from a backup. I am (10GE Attached) getting a peek of 2.7Gbps (on unRAID screen and 1.4 on my switch) with docker off, and drops to 120Kbps with it on (with the system on the array).

 

Would this be expected? 

once the mover moves appdata and system to the cache (dual 1TB SSD) then I will try again, but curious if this is a known situation.

Edited March 27 by kcossabo

[trurl]

32 minutes ago, kcossabo said:

changed it to the cache, and invoked the mover

Nothing can move open files. You have to disable Docker and VM Manager in Settings before these can be moved.

[kcossabo]

Oh, the VM Manager… I stopped the Docker, but not the VM. I have no VM, but it is enabled.

 

[trurl]

5 minutes ago, kcossabo said:

I have no VM, but it is enabled.

Then libvirt.img is an open file in the system share.

[kcossabo]

I will reboot, after stoping VM and Docker, the mover has not completed in over 30 minutes. 

[kcossabo]

@trurl Thank You for the help. I reboot (array is not set to start, yet, on reboot), and

 

- created a share 'system2'

- move all the files from system to the new system2 (used MC at the CLI)

- destroyed share, created share system on the cache (system)

- moved data back from system2 to system 

Now I am totally confused. 

1) Docker is set to 

/mnt/user/system/docker/docker.img

 

2) that share is on the cache, but has no files?



3) If I navigate to the share and look at the files, they are on the array, not the cache



Appreciate the help, I will keep pocking at this.

[trurl]

Post new diagnostics

[kcossabo]

I will, and I found the problem. 

When MC is used to move a directory in this casespacestation-diagnostics-20240328-1026.zip

/mnt/usr/system/* -> /mnt/usr/system2/

Even though system2 is on cache, the files do not move. (just tested it with my trouble shooting)

If I Copy them, they do actually appear on the Cache.

[trurl]

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

[trurl]

Here is a post I made some time ago about 2 "surprises" to watch out for

 

[trurl]

These latest diagnostics shows appdata, domains, and system shares with files on the array.

 

Ideally, these would all be on cache or other fast pool, so Dockers/VMs will perform better, and so array disks can spin down since these files are always open.

[itimpi]

24 minutes ago, kcossabo said:

I will, and I found the problem. 

When MC is used to move a directory in this casespacestation-diagnostics-20240328-1026.zip

/mnt/usr/system/* -> /mnt/usr/system2/

Even though system2 is on cache, the files do not move. (just tested it with my trouble shooting)

If I Copy them, they do actually appear on the Cache.

that is a quirk of the way Unraid UserShares interact with the underlying Linux system and is mentioned in the User Shares part of the online documentation.    If you had instead used Dynamix Fiile Manager to do this you would have gotten the expected result as that implements ‘move’ using a copy/delete strategy.

[kcossabo]

1 hour ago, itimpi said:

If you had instead used Dynamix Fiile Manager

 

Fun story, I played with that, but, it took to long to move files compared to MC.... now I know why. I thought it was because it was in a container. I assume it will work with docker turned down?

[trurl]

Dynamix File Manager is a plugin and will work with Docker disabled. It will be built-in with v6.13