apandey

if the disk wasn't disabled, and all you are getting are UDMA CRC errors, you should look at connections first (SATA / Power). Replace cables, check they are properly attached etc. It's more likely a connection issue than disk issue. Since you have reassembled, its more likely too
If that doesn't help, run extended SMART test on the disk before you decide to replace it. Replacing disk would make it look like disk issue if all it does is reconnect new disk properly

There should be no effect from data point of view. Parity needs to be valid at any point on every disk sector. The read write mechanism needs to be consistent and unraid guarantees that. You will be checking the state either before or after your ongoing writes, never an inbetween state. Same with writing corrections
 
You may still want to minimize array access during parity checks, because fast parity checks depend on sequential IO. If the drive heads have to move between parity read and data read often, that leads to very slow random IO. So there is a performance concern 

If the other disk is spun down, there will be a slight lag. But that's it. I don't worry about this for a use case like streaming a show. Single files are self contained on a single disk, so it's not like reads are randomly jumping disks in real time
 
As for managing across drives, you should look at user shares documentation here: https://wiki.unraid.net/Manual/Shares#User_Shares
 
Specifically, allocation method, free space strategy and split levels and how they work together to manage storage across drives

Remove the drive you added from the pool. Then add it as a new pool
https://wiki.unraid.net/Manual/Storage_Management#Removing_disks_from_a_multi-device_pool

You should look in syslog, the error while mounting should be logged there 
If not sure, post diagnostics 

Wifi is still a no go
 
Power line, depends. But it does bring uncertainties into the mix based on your home wiring. It might work for you though, so it's an option
 
A more reliable solution can be a wifi bridge - basically a wireless uplink to ethernet 

Install the fix plugin mentioned in this thread - 
 

Perhaps you can try file activity plugin to narrow down the cause of writes

You can reset the network by deleting /config/network.cfg from the USB boot drive using another computer

Would it help if you managed your custom exports under /etc/exports.d/ instead? That way no conflict with whatever unraid might be managing in /etc/exports

Do you have local network sharing enabled in your VPN app? https://mullvad.net/en/help/using-mullvad-vpn-app/#localnetworksharing
 
Without this, every connection will be router to VPN and will exit from VPN IP which obviously has no route back to your local network

I mostly go to the manual. See if this helps
https://wiki.unraid.net/Manual/Storage_Management#Removing_disks_from_a_multi-device_pool
 
If your disk to remove is a separate pool by itself, simply make sure it's not used by any shares, has no data on it and then you can just delete the pool
 
If you are not sure, post diagnostics or a screenshot of your main page to get further advise

You should trap SIGTERM and terminate when you see it. How you do it is up to you - set a poison pill variable or kill $$
 
EDIT: SIGTERM is sent to process initially on shutdown, but a SIGKILL is also sent subsequently. So just make your script handle the signals properly

Correct, parity drive will be completely overwritten during parity build. No point pre clearing except for stressing the drive to make sure it's good for use

I restarted nginx via ssh and that fixed it. so, at least have proved that only nginx was out of order
 
still wondering what the underlying issue is. it will very likely happen again 😬

Just an update on this... identified the bad memory module. Now running longer memtest again with remaining modules to make sure no other issues