Thanks a lot for all the information…
It seems I was on the wrong path with a hardware issue and now I tend to favor an issue with snapshots, indeed, and thus agree with your impression.
We have seen some systems showing slow downs when using a high number of snapshots, especially when combined with quotas being enabled. As the latter is the default Btrfs setting, unless you manually disabled it (which is possible using the webUI), you likely have them enabled.
Have a look at the post below:
In particular, I would try to run the command below to see how many snapshots you have:
btrfs subvolume list /mnt2/<you-pool-name-here>/ | wc -l
The Btrfs usage report is also always a good thing to check, even if it’s unlikely to reveal something wrong in your case:
btrfs fi usage /mnt2/<your-pool-name-here>
@phillxnet explained very well the situation in which you may find yourself (too many snapshots) in the post I linked below, so I recommend trying his recommendations therein. In particular, he explains how deleting a snapshot is a very “intensive” task (relatively), which would particularly explain why you saw the first webUI error (in your first message) related to deletion of snapshots (the system was probably taking a little while trying to deal with the task and the API request timed out, resulting in the error you received).
This is in @phillxnet’s area of expertise so he can probably correct me if I’m wrong there.
Hope this helps,
PS: nice system you have there, by the way!