Hi all,

Unraid 7.3.2 - diagnostics.zip attached

I've just started running Unraid on a new TerraMaster F4-425. I'm in the middle of a large read-only copy from an 8TB Seagate mounted via Unassigned Devices into the array, using binhex-krusader (Docker container).

What went wrong:

• the copy ran smoothly up to about 60% at roughly 180 MiB/s

• overnight (I think at 2am?), the transfer paused waiting for user input on an errno 5 (I/O error) for a single file

• the next morning I dimissed the prompt and the copy resumed — but speed has been stuck at 70-80 MiB/s ever since
  

Troubleshooting so far:

• stopped and restarted the Krusader copy job

• rebooted the Unraid server

• reseated all drives in the bays

• pulled SMART attributes for the source Seagate via the Unraid web GUI:

  • Reallocated_Sector_Ct: 0

  • Current_Pending_Sector: 48

  • Offline_Uncorrectable: 48

  • Reported_Uncorrect: 44

  • UDMA_CRC_Error_Count: 0

  • Power_On_Hours: ~47,652 (~5.4 years)

Given UDMA CRC errors are at 0, I don't think this is a cabling/connection issue. The pending/uncorrectable sector counts (48) line up suspiciously with the errno 5 event, and I suspect the drive may be spending extra time internally retrying reads on marginal sectors, but I'm not certain this explains a sustained 2x+ slowdown across what should be mostly healthy sectors.

Questions:

1. Does anyone have any idea what caused this and how to fix it?

2. Does a handful of pending sectors on a source drive typically cause this kind of sustained, drive-wide slowdown rather than just a local slowdown when reading the specific affected files?

3. Is there a way to confirm (via Unraid GUI or terminal) whether the drive has silently dropped to a lower SATA link speed after the error, and if so, how to force it back to full speed?
   
   

Thanks!

rosa-diagnostics-20260717-0841.zip

Edited July 17Jul 17 by g7e
typos

That disk appears to be failing; you can run an extended SMART test to confirm.

I plan to run an extended SMART test once I've copied the data off the drive. In the meantime, I'd like that copy to happen as quickly as possible, thus my question.

I/O errors are normal if the files are occupying a failed sector, since the disk will not return a corrupted file; speed fluctuations are also normal with a failing disk. A possible option to get most of the data is using ddrescue https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-525075

Might not be related at all. What's the current destination of the copy? I see you have a 16TB drive and a small 4TB, if something is currently being transferred to the latter it'd be way slower than the 16TB.

But a failing drive in general can have highly varying speeds. Regions that do not fault completely might take more effort to read/recover.

Edited July 17Jul 17 by Kilrah

The destination of the copy is an array made up of the 16TB and a 10TB. It's an interesting point. I noticed when the copy started that the writes were going to the 16TB disk and now they're going to the 10TB disk so it's possible that 10TB is significantly slower and that's what's caused the change. Perhaps that single errno 5 is a red herring and unrelated to the speed change.

(Just as background, I started the array with the empty 16TB, then I copied the contents of the 10TB into the array, formatted the 10TB and added it to the array. Now I'm doing the same thing with the 8TB - coping the files off it so that I can add it to the array although obviously there are now concerns about its health.)