armageddon421

I think this feature would be awesome! The current options either leave your data unprotected, take many steps and much time or you end up with the more expensive and inflexible parity 2 in single parity setups. This would allow basically zero downtime and require less performance penalty than a regular parity rebuild, as reads from data disks are not affected at all, while still retaining full protection throughout the process. My feeling is that it wouldn't be too hard to implement this, as it is basically just running dd from the old to the new parity drive, while also mirroring every write that happens to the old drive to the new drive, but only if it happens in the area that was already written to by the dd'ing process. After the dd is done, only the write-mirroring remains to keep the drives in sync until the user decides to drop the old parity drive. Maybe this "replace disk" feature could even work for data disks as well? The approach should not be different there. I'm looking forward to seeing this idea develop!

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!

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.

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.

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?

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.

Nope, running bare metal.

Same for me, no problem since the downgrade.

Correction: I was on 6.12.8 before. I'm reverting back to 6.12.8 now to see if that fixes the issue. I hope this will be resolved in the current versions soon.

Just downloaded the diagnostics logs, there is absolutely nothing around the time it must have died, and very little in general.

It happened again this night, from logs I can see it must have been just 1.5h after I rebooted unraid. On the client machine, all processes accessing the NFS share are stuck in CPU_IOWAIT state. Even "ls" on a mount is just stuck for minutes already now. The only other thing I changed to make NFS work reliably in the first place was to disable hard links. There are only two shares exported, they are set to private and can only be accessed from a certain VLAN/subnet.

I had a similar thing just happen. Upgraded from 6.12.9 to 6.12.13 last week, used NFS only sporadically. Today after a few hours of continuous use, it suddenly became completely unresponsive, even breaking ongoing file transfers. rc.d/rc.nfsd restart did not help at all, there were a handful of [nfsd] processes listed in ps/htop and they did not change at all when issuing rc.nfsd stop/start. Resorted to a full reboot, that fixed it (for now). Everything else seemed tottally fine with unraid (SMB/docker/VMs).