I started a move from disk 2 to disk 5 because disk 2 became full. To speed things up, I thought I'd enable turbo mode. What I got made me concerned.

As you can see in the screen shot, the other disks still are not doing anything (although manually spun up), but the read speed on the writing disk and parity is now much lower than the write speed. Where is the parity data now coming from? Is something broken or am I just not understanding something?

Before enabling reconstruct write, the three read speeds and the two write speeds were exactly the same, but much lower than now at around 60MB/s.

Edited August 11, 2025Aug 11 by armageddon421

Turbo write is automatically disabled if/while there are writes to multiple disks.

33 minutes ago, JorgeB said:

Turbo write is automatically disabled if/while there are writes to multiple disks.

I understood that, but why would the behavior then change at all? Where does the parity data come from if not from reading the disk that is written to and the parity disk at the same speed as they are writing?

Also, moving from one disk to another is just writing to a single disk, but also reading from another. So it should still work, right?

Edited August 11, 2025Aug 11 by armageddon421

for comparison, this is what it looks like with reconstruct write off. All read and write speeds are equal, and that makes sense to me.

With reconstruct write enabled, I would either expect nothing to change or all drives to be involved.

41 minutes ago, JorgeB said:

Turbo write is automatically disabled if/while there are writes to multiple disks.

Misspeaker here; it happens when there's i/o from multiple array devices, including reads.

1 minute ago, JorgeB said:

Misspeaker here; it happens when there's i/o from multiple array devices, including reads.

Okay, then that explains why it does not actually do reconstruct write, I can live with that.

What I still am worried about is why does it write faster then? Clearly something changes and I do not understand where the parity information is coming from in that case.

With the case from the scresnhot it can still be faster because only parity and disk5 are 20TB, and disk is almost full, so it's wrting to a zone that's it's not covered by the other array disks, it can still enable turbo write for some moments, but no readson for concern, just performance may not be fully turbo write when doing that, it will adjust automatically.

Ah gotcha, I was just thinking something similar while staring at it again. Because the target drive is the the only other drive as big as the parity drive, it is probably writing mostly beyond the 6tb mark, therefore not needing any information from the other drives for parity.

Then it's just a shame that read/modify/write is not smart enough to do this automatically as well, the read part is actually completely unnecessary in that case.

Thanks for helping me clear this up!