Parity Sync ETA is over a Month, Docker fails to initialize, Drive transfers are slow, Reboots fail.

[Discordant]

Hello all,

 

Running into some real weird issues here. Physically relocated my unraid server from my bedroom down into a rack in the basement after I finished building and testing it. That's when I started experiencing some issues. First my Overseerr instance was no longer available over the internet w/ a 502 bad gateway. I turned off and one the setting for Host access to Custom networks and that seemed to resolve it.

A reboot later and it would get stuck in the BIOS and later have issues w/ something regarding the USB where i'd have to remount it and restart a couple of times. (don't recall exactly)

 

When I successfully boot, NGINX reverse proxy still has issues but when i try the previous fix online I saw docker will fail to initialize. I am migrating files over from a previous NAS and even moving files internally i'm only seeing speeds of around 10 mbps. Same with my parity sync which is quoting me around 30 days. It seems like a perfect storm of things that just all happened at once.

 

Attached are my diagnostics. I'm relatively new to unraid and have been using it for maybe less than a month. Hopefully someone can maybe steer me in the right direction to get this all sorted out. On 6.10.3

blackpearl-diagnostics-20220703-1744.zip

Edited July 3, 2022 by Discordant
OS version

[trurl]

1 hour ago, Discordant said:

I am migrating files over from a previous NAS and even moving files internally i'm only seeing speeds of around 10 mbps. Same with my parity sync which is quoting me around 30 days

I recommend not doing large data transfers and parity builds at the same time. It can only result in a lot of seek delays (disk thrashing) since writes to the array must update parity, and parity and all other disks are already busy from the parity build, and they must constantly go back and forth between reading and writing the sectors for parity build, and writing other sectors for data transfer. So a lot of moving of heads and rotation to get to the correct place on the disk for these different operations.

 

Many people will wait until after initial data load to even add a parity disk so the transfer won't need to update parity.

[Discordant]

40 minutes ago, trurl said:

I recommend not doing large data transfers and parity builds at the same time. It can only result in a lot of seek delays (disk thrashing) since writes to the array must update parity, and parity and all other disks are already busy from the parity build, and they must constantly go back and forth between reading and writing the sectors for parity build, and writing other sectors for data transfer. So a lot of moving of heads and rotation to get to the correct place on the disk for these different operations.

 

Many people will wait until after initial data load to even add a parity disk so the transfer won't need to update parity.

 

Noted! I canceled the parity sync for now and will remove the parity drive in the meantime. Thanks for that tidbit of knowledge. Do you think that can be cause for a lot of the underlying issues that i'm running across? I'm wondering if the USB somehow got corrupted already despite not being used for that long? 

[trurl]

Why do you have 100G docker.img? Have you had problems filling it? That is several times larger than should be necessary. The most common reason for filling docker.img is an application writing to a path that isn't mapped to host storage. I usually recommend 20G, maybe 30G if you have a lot of dockers. Making docker.img larger won't fix filling it, it will only make it take longer to fill. Used space in docker.img shouldn't grow.

 

What is the purpose of this cache-only user share V--------------s ?

[Discordant]

5 minutes ago, trurl said:

Why do you have 100G docker.img? Have you had problems filling it? That is several times larger than should be necessary. The most common reason for filling docker.img is an application writing to a path that isn't mapped to host storage. I usually recommend 20G, maybe 30G if you have a lot of dockers. Making docker.img larger won't fix filling it, it will only make it take longer to fill. Used space in docker.img shouldn't grow.

 

What is the purpose of this cache-only user share V--------------s ?

 

I believe I originally had a problem w/ the docker image getting full and increased the size temporarily and forgot to shrink it back down.

Regarding the user share, that was going to be dedicated for a gaming virtual machine until I realized that I couldn't use my GPU for transcoding and VM pass through. haha. Decided to use it for the former and actually just removed that share after you mentioned it. 

[trurl]

Some other recommendations about your user shares we can deal with after you finish initial data load then parity sync. Since none of them are writing to cache it should be fine for now. Might as well disable Docker in Settings until all that is taken care of.