My last dozen parity checks have run at 123.1MB/s at the slowest to 189.3MB/s at the fastest. Eyeball average around 130-135ish.

My start-of-month parity check kicked off on the 1st and is running at about 55MB/s!

• I paused all docker containers, and that didn't made a lick of difference in the speed, so I don't think it was them to begin with.

• I recently added a new disk and it's a bit slower than the existing ones but it's not this slow! The disk speed test in the Disk Location plugin indicates the slowest of my drives is around 167MB/s (eyeball avg of last 12 test speeds), and my new Parity drive is sluggish at 184MB/s. The rest (eyeball) average about 220-230MB/s.

• My parity rebuild (when I added a new drive and a new, larger parity drive) was somewhere in the 100+MB/s range (don't recall, but it was a reasonable number - nothing to raise any concern).

Almost all my disk access would be through one of the docker containers (immich, Emby, Jellyfin, etc.), so I don't think I had anything actively reading/writing (when I paused containers) other than the parity check. I've got a couple of File Explorer windows open to unraid locations, but that's it, and certainly not anything I wouldn't have had open on previous runs.

I stopped the parity check yesterday out of frustration. It kicked off again overnight (there was an unclean shut down due to power outage - I guess the UPS battery life isn't as optimist as the screen reports) and today it's running at about the same speed.

nas-diagnostics-20260404-1211.zip

Any thoughts/ideas on why this is suddenly running at ~1/3 to 1/4 the speed it normally runs? Any possibility that a reboot might fix it? If a reboot fixes it, any suggestions on what to do to prevent this slowdown again in the future? I don't recall ever having a parity check run this slowly...

Now it's slowed down to 24-26MB/s! 😢

There are some writes going to disk6, appears to be minimal to cause that slow. Still good to stop everything; if still slow, run the diskspeed container to see if the disks are performing normally.

34 minutes ago, JorgeB said:

There are some writes going to disk6, appears to be minimal to cause that slow. Still good to stop everything; if still slow, run the diskspeed container to see if the disks are performing normally.

Thanks for looking!

I've stopped all containers. Didn't make any difference to read speed, well, it had recovered from the 25MB/s range back up to the 50s, and now it's in the 55-58MB/s range, and I'm still getting random writes to disk 5.
I've shut down every application on the 3 computers that would be accessing the server. I don't have a clue where those writes are coming from.

Can I run the diskspeed test while the parity check is running or should I pause it? I'd presume I should pause for accuracy...

I even rebooted my desktop machine and I'm still getting the writes on 5 & 2.

Then I realized I've got a VM running! 🤦‍♂️
I've shut it down, but I'm still getting some writes. I'm also getting some all-drive reads and a parity drive/drive 2 write combos. Something is still active on the server, but I'm at a loss...

Diskspeed test results:

The comments on the run:

Bandwidth was capped on the following drives: flash (sda), Disk 9 (sdj)
Notice: A "Speed Gap" was detected on a drive which means the amount of data read from one second to the next had a speed difference in
excess of a given amount and was retested.
This is typically a sign of activity on the drive from another process but may be due to a troublesome spot and the drive's internal error correction working.
If you keep getting Speed Gap warnings on a drive, abort the benchmark and set the checkbox for "Disable Speed Gap detection" on the benchmark section.

600 Series Chipset SATA Controller: Done

800 Series Chipset USB 3.x XHCI Controller: Done

SAS3008 PCI-Express Fusion-MPT SAS-3: Done

SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]: Done

Disk 3 is a bit of an outlier and slower than the rest, but none of them are 50MB/s slow!

The test is completed and something is still pushing little blips to disk2, and my parity check is still running at 57MB/s...

I was getting a number of Speed Gap warnings, so I decided to run it with that disabled. I think I found my problem:

The question now: Why has Disk 2 suddenly decided to read so slowly??? My last parity check last month:

Hard to believe that the overall speed would have climbed to 189MB/s after a start like this from disk2.
There's nothing in the SMART data that indicates there are any issues, at least not to my untrained eye.

I'm open to any & all suggestions/fixes.

It finished just as I posted that. Overall, it's a pretty bleak picture without the Speed Gap detection.

Again, though, on March 8th was one of my fastest parity checks ever, including this 14TB drive as the parity drive.

Disk 11 (the wavy orange line extending to 12TB) is the only drive added since that last check, but it shouldn't be impacting the 1st TB speed this severely.

It's been a while since I've run that test, but there may be one or more disks with slower sector zones causing the problem.

It may still be worth starting a check in maintenance mode, to rule out any other disk access.

According to the diagnostics you posted earlier, your system share is on disk2. If Docker and/or VM Manager is enabled in Settings, system share has open files. Your domain share is also on the array.

Well, I've just let it run. It's now 10TB and running around 120MB/s, though I did note one brief drop to about 20MB/s.
I wish there was a way to record the speed every second/minute & graph it and see if the graph at all looked like the disk speed test graph...

Well, it finally finished! My last parity builds/checks since I installed this 14TB parity drive:

Scheduled Non-Correcting Parity-Check	2026-04-07, 03:48:18 (Tuesday)	14 TB	2 day, 7 hr, 32 min, 8 sec	70.0 MB/s	OK	0	2 day, 8 hr, 36 min, 4 sec	5
Scheduled Correcting Parity-Check	2026-04-03, 19:11:09 (Friday)	14 TB	1 day, 13 hr, 13 min, 57 sec	104.5 MB/s	Canceled	0	1 day, 14 hr, 31 min, 59 sec	3
Parity-Check	2026-04-01, 11:53:25 (Wednesday)	14 TB	3 hr, 17 min, 2 sec	Unavailable	Canceled	0
Parity-Sync	2026-03-08, 12:48:33 (Sunday)	14 TB	20 hr, 32 min, 53 sec	189.3 MB/s	OK	0	1 day, 20 hr, 56 min, 54 sec	4

I don't get it. I guess we'll see how it goes next month...

Did you do this?

On 4/5/2026 at 5:39 AM, JorgeB said:

It may still be worth starting a check in maintenance mode, to rule out any other disk access.

Because

On 4/5/2026 at 8:36 AM, trurl said:

According to the diagnostics you posted earlier, your system share is on disk2. If Docker and/or VM Manager is enabled in Settings, system share has open files. Your domain share is also on the array.

6 hours ago, trurl said:

Did you do this?

Not yet - I wanted to let the check finish since I was so many hours into it.

I'm pondering now, though, how do I use the Disk Speed Test container when the array is in Maintenance mode? Doesn't that prevent Docker & VM from running, which means I can't run a container?

On 4/5/2026 at 8:36 AM, trurl said:

Your domain share is also on the array.

Is it recommended to have this on cache somewhere?
I've got space on an SSD pool that I could easily move it.

Ideally, Docker/VM related shares - appdata, domains, system - would have all files on cache or other pool with nothing on the array, so Docker/VM will perform better, and so array disks can spin down since these files are always open.

Or in your case, so array disks won't be busy during parity check or rebuild.

18 hours ago, trurl said:

Docker/VM related shares - appdata, domains, system - would have all files on cache or other pool with nothing on the array

Thanks for the tip!
Both domains & system are now set to live on the 'apps' share (with the mover set to move array -> apps), along with my appdata share that was already there. I'm using barely 100GB out of the 1TB of space in that array, so I'm sure there will be plenty of space.

I can stop the VM service and shut down all containers except the disk speed test to run it clean, if you think that would be of benefit. Otherwise, I'll just wait until 1 May to see what happens...

9 minutes ago, Free Man said:

domains & system are now set to live on the 'apps' share (with the mover set to move array -> apps)

Nothing can move open files. You have to go to Settings and disable Docker and VM Manager before mover can do that.

For the record: I did shutdown VM & Docker, run mover, and start them back up.