plots check hangs and hoses proxmox network bridge

[GCTWorks]

Whenever I run chia plots check, it hangs on one of the tests. This hoses the network connection to the NFS share where my plots are stored.

Chia version: 1.6
OS: ubuntu 22.04.1
Virtual Machine running on proxmox 7.3-3
VM has two network interfaces:

1. one for general network connectivity and access to the internet
2. this is a DIRECT connection via a proxmox Linux Bridge to my NFS file share on a TrueNAS Core server.

Everything with the network works great until I run chia plots check. After running that command, the VM and proxmox itself can no longer communicate with the TrueNAS server. The VM and Proxmox can communicate with each other though.

I can do an ifdown then an ifup on the Linux Bridge in proxmox and the connection comes back.

I am not sure if the plot check command is causing this to happen or if I have a problem with my direct connection. Logs, at least the ones I have looked at, do not show anything, or I do not know what I am looking at.

I lean towards there not being a problem with the connection because I was able to transfer ~14TiB across it over around 18 hours in one shot with no problem. (I moved the plots). Also, the farmer does not seem to care that the plots are on the NAS during normal farming.

Any thoughts? Need more information? Any troubleshooting tips?

[MumfMeisterT]

This may be caused by corruption in one of the plots or one of the drives. You might try removing drives one by one to see where this issue might be coming from.

[GCTWorks]

I cannot remove the drives as they are part of a zpool on my TrueNAS Core server. That would take down the pool. I tried this on a different pool and it still happens. If I use check plots -n 5, it will do this too, but will actually get through some of the plots. It is different each time. What is happening that it causes a virtual network interface to get hosed up?

I know that the network connection is good as I was able to transfer about 14TiB of data continuously across the link with no problem. At least, this gives me high confidence in it.

[GCTWorks]

I can cause something similar when the db and wallet directories are also located on the NAS. However, with the wallet on the NAS, the farmer cannot even start before the network interface is taken down. If only the db directory is on the NAS, this failure will eventually occur.

Is this a bug?

This is really challenging as the db directory keeps growing past my virtualization server capacity.