I'm in the process of rebuilding my parity.  I had updated a few drives to 18TB so I could later move off a bunch of my 2TB drives and shrink the array.  Rebuild was going great for the first 24 hours or so..  I had approx. 28 hours to go and then the speed dropped way off and the estimated time jumped up to 60+ days.  I turned off the VMs and the Docker services so the only thing running would be the rebuild and that helped a bit, but it's still saying around 30 days.   In the past 10 hours it has gone from about 54% complete to 55.6% complete.   CPU utilization is only at 3% or so RAM at 16%.  
I did have some read errors on one of the disks earlier on in the rebuild..  69 errors on one of the 18TB drives (disk20) but when that happened it really didn't slow anything down and ran strong for hours after that.  At this point, all of the 2-4TB disks are no longer being read, just the 6   18TBs, so I actually thought it would run faster at this point.   I'm really not sure what to do at this point as everything appears to be running fine, just extremely slow for whatever reason.

unraid-diagnostics-20250316-1036.zip

There's something else accessing the array disks, also in case you've missed, there were read errors on disk20 during the parity sync.

Absolutely nothing else is accessing it, I had turned off Docker and VMs, even killed network for a while to test to make sure of that, and yes, as I mentioned in my post, there were 69 read errors early on in the process and it ran smooth for several hours after that..   My cache pool was pretty full, all my isos, appdata, system, logs, and domains are on the cache pool and I was able to free up a good amount of space by removing some snapshots, and that made things go slightly better, it allowed me to turn the VMs and Docker back on, which makes sense, but it didn't really do anything for the parity sync.  I turned Docker and VMs back off to let it run a bit more but it would still top out at 2.0MB/sec max which appeared to be a write limitation.   Finally I just cancelled it, rebooted, and started over..  Wait to see if it slows again around the 50% mark.

26 minutes ago, meat said:

Absolutely nothing else is accessing it

The diags show otherwise, you can start in maintenance mode and retest, nothing can access the filesystem like that

2 hours ago, JorgeB said:

The diags show otherwise,......nothing can access the filesystem like that

Help me to understand what you are seeing in the diags to show that something else is hitting the array, or explain what else can hit the array, I'm drawing a blank on anything that could be..  VMs and Docker off and nothing on the network hitting it, I even killed network just to be safe..   I'm not sure what else internal to unraid would be hitting it..   system files and logs hitting the cache, watching the drive read / writes, I'm only seeing what would appear to be a parity sync.    If something else accessing it, I'd see way more reads or writes.  Are there processes in place that will throttle the sync for any reasons if say for example, CPU utilization gets too high?  If that were the case, possibly it got stuck in that mode even after CPU dropped down.    When it first started getting slow, everything just bogged down, I knew it had dropped off because my VM I had running had stopped working.. CPU was high at that time, that's when I shut everything down except the sync..  but those speeds never came back up..    I cleaned up cache and the cache returned to normal utilization levels, I was able to then turn back on VM and it all worked..  but the sync speeds never returned to what they should be.

Taking a more careful look, there is some extra activity, but it's minimal, so that may not the problem, but there are still a few writes to disks 6 and 7, so difficult to say if that is actually a problem, but there is something still writing to the array, so see if you can stop that, and if after that the speed remains slow, you can run the diskspeed docker test to look for a slow disk.

 

 

In loads.txt, it shows the current read and write speed for all devices, and for the array devices it shows:

 

sde (disk16)=2125824 0 21397603 71
sdf (disk1)=28672 0 7126725 99
sdg (disk3)=28672 0 7128629 99
sdh (disk8)=28672 0 7121130 92
sdi (disk9)=2125824 0 21400248 78
sdj (disk21)=2125824 0 21398272 5650
sdk (disk4)=28672 0 7126519 90
sdl (disk5)=28672 0 7126607 106
sdm (disk10)=28672 0 7124206 102
sdn (disk2)=28672 0 7126911 105
sdo (disk20)=2125824 0 21398722 78
sdq (parity2)=0 1873920 193 21225801
sdp (parity)=0 1873920 193 21225798
sdr (disk14)=2125824 0 21397685 351
sds (disk15)=2125824 0 21397674 72
sdt (disk6)=28672 22528 7126636 89
sdv (disk11)=28672 0 7129543 95
sdw (disk12)=28672 0 7129013 95
sdy (disk13)=28672 0 7129196 100
sdz (disk7)=28672 16384 9379342 99
sdx (disk17)=28672 0 4813715 100
sdaa (disk18)=28672 0 9379023 87
sdab (disk19)=28672 0 9378870 91

 

First value is the read speed, in bytes/s, then write speed, the remaining two are irrelevant in this case, during a parity sync, only parity(s) should show write activity.

that's interesting..  I'm not sure what that would have been, those 2 disks would have essentially be done with their part of the sync as I was way past the 4TB point..  Not sure if the actual diagnostic running wrote at that time or not...    I've restarted the sync and it's humming along for now..  at 16.1%    Tomorrow morning I should know if it's going to hang at the 50% spot again and I will look into those drives, etc..     for now I guess just wait it out..

well the good news is..  on the second attempt I've gotten to the point where it's only the 18TBs left and the speed nearly doubled, writing at 165MB/sec now...  fingers crossed it keeps this up.