Actually the reboot “fixing” it is easy to understand: it’s not actually fixing anything.
If the HDD are device managed SMR drives, then the HDD is saying to truenas that the information is written when it has not yet been placed into the singled areas. So cancelling the copy and then rebooting is probably wiping out information which truenas thinks has been written but hasn’t, and then when the copy is restarted on a new file previously “written” blocks might be missing. Yay data loss.
The reason it “works” is that the cache is emptied, and then when the file transfer is restarted it goes back into the drive cache before it gets written into the shingles, so it looks like the drive is copying at a faster rate again.
Look, I’m no where close to an expert on this subject, but I do have two crappy SMR drives (Seagate Barracuda) that I’ve played around with in truenas and I can say this: all performance is slower than the CMR drives I’m using (Ironwolf Pro). The writes slow down. The reads aren’t great either even when using metadata vdevs (so the metadata is on an NVMe drive, not the SMR HDD). The difference in performance is down to the the nature of SMR drives, if you’re looking for a “why” answer maybe the thread above can help you with it.