I am trying to downsize my array and remove some disks. I am following the guide from https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array-configuration/#removing-disks for removal without losing parity. I have done the umount, truncate, mkfs, and mount commands and the gui now shows a 400MB empty disk like it should. When i started the dd command it was super slow. when I cancelled the command in the console it had done 1GB in 10 minutes and in the web gui it shows (with reconstruct write turned on) about 550-600 KB/s writes on the parity drives and the one I am removing and about 60-70 KB/s reads on all disks, including the one I am removing. It has now been quite a while since I cancelled the dd command and I am waiting to try again with oflag=direct, as per suggestions i found, but the array is still doing its extremely slow operations.

Any suggestions?

The standard dd comand shoudl work fine, there may be an issue with a disk slow reading or something else accessing the array; diagnostics may give a better idea.

I am generating the diagnostics right now. Takes a while with many disks,
Nothing was accessing the array.
No disk errors.
Nothing unusual in syslog...

I have sent the diagnostics to you, @JorgeB .

Next time, please post them here; they are anonymized by defualt.

Lots of spam on the syslog, but not seeing any disk errors; could just be one of the disks being accessed has slow sectors.

One thing I just noticed is that the dd command is missing the block size, so it will revert to the default 512 bytes, which can be much slower. Try adding bs=4K to the command.

Edit: It's not missing; it's at the start of the command, but test with 4K instead of 1M, just in case one of your disks doesn't like 1M.

Thanks I will try that, but my array is still doing parity calculations from my previous try and it's been over an hour now since I cancelled it.

It can take some time to flush the RAM, or a lot of time if the speed is so slow.

Yeah. The question is why it is so slow though.

I ran these commands, I suppose they are correct:

umount /mnt/disk26

truncate -s 400M /tmp/26mini.img

mkfs.xfs -f /tmp/26mini.img > /dev/null

mount /tmp/26mini.img /mnt/disk26

dd if=/dev/zero of=/dev/md26p1 bs=1M status=progress

I was thinking of just saying "screw you" to my server and stop the array, remove the disks I was gonna remove and let parity recalc, but I am afraid it may do that in this speed as well.

Edited September 23, 2025Sep 23 by Xorius
Added comment about removing disks and let parity recalc

I've recently seen another user with bad speed using that command, so I suspect the 1MiB block could be a problem with some devices, or the md driver and some devices, though technically it should work fine with all, but it's worth trying with 4K just to make sure.

I did try it with 4k earlier, but parity was still being written from the previous operation, got tired of waiting. it went quite quickly up to 1GB, then basically stopped.

1 hour ago, Xorius said:

but parity was still being written from the previous operation

That's not really a good test, if you can please try later and let us know if it's the same.

For some reason, the exact same command I used earlier works fine now. The only difference I noticed is that the previous time the disk was asleep and had to be waken up. Maybe that caused som kind of confusion.

I believe I've seen issues before where some disks don't perform correctly if woken from sleep with dd.