gfjardim

You have to go to Tools > New Config, set Preserve current assignments to None, check Yes I want to do this and then click Apply.

So you will preclear an empty drive and then add it to the array? Empty the contents another drive into the array, preclear this one and then add it too?

Do you already created your parity?

Array drives aren't supposed to be removed like that; or you replace the drive with another with the same/larger capacity, or you have to invalidate the parity to do that. What dou you want to accomplish?

For that amount of disks failing preclear, my guess is indeed memory errors, but he got disks dropping out too like "/dev/sde" and "/dev/sdg".

After remove the drive from the array, you have to start the array again to remove any references of it.

Maybe hard disks internal cache?

Direct bypasses both data cache and I/O queueing; nocache bypasses only the data cache. The performance can be dramatically different depending the amount of I/O the device supports and how it manages it's I/O requests without the kernel I/O queue: No caches, I/O queue, 512 bytes read block: root@Servidor:~# echo 3 > /proc/sys/vm/drop_caches root@Servidor:~# dd if=/dev/sdh of=/dev/null count=1048576 iflag=nocache 1048576+0 records in 1048576+0 records out 536870912 bytes (537 MB, 512 MiB) copied, 2.14517 s, 250 MB/s No caches, I/O queue, 1M read block: root@Servidor:~# echo 3 > /proc/sys/vm/drop_caches root@Servidor:~# dd if=/dev/sdh of=/dev/null bs=1M count=512 iflag=nocache 512+0 records in 512+0 records out 536870912 bytes (537 MB, 512 MiB) copied, 1.98191 s, 271 MB/s No caches, no I/O queue, 512 bytes read block: root@Servidor:~# echo 3 > /proc/sys/vm/drop_caches root@Servidor:~# dd if=/dev/sdh of=/dev/null count=1048576 iflag=direct 1048576+0 records in 1048576+0 records out 536870912 bytes (537 MB, 512 MiB) copied, 217.961 s, 2.5 MB/s No caches, no I/O queue, 1M read block: root@Servidor:~# echo 3 > /proc/sys/vm/drop_caches root@Servidor:~# dd if=/dev/sdh of=/dev/null bs=1M count=512 iflag=direct 512+0 records in 512+0 records out 536870912 bytes (537 MB, 512 MiB) copied, 2.12653 s, 252 MB/s

Did not took a screenshot, but the controller benchmark showed greater speed values when all disks were read together, probably because they were already read one at a time. When I dropped the cache, it returned to normal behavior. I had better luck setting "iflag=nocache" parameter rather then the iflag=direct before. I think it worth trying.

Hi @jbartlett, just now I've tested your app, and it's magnificent! Well done, pal! One thing I've observed is that apparently disk reads are being cached. There are options in dd that prevent this behavior, did you use them?

That's correct. It creates a GPT Protective partition so Unraid can recognize it. We must remember that when Unraid was first launched, we only had MBR partitioning scheme and disks were far from archiving more than a few gigabytes. This was the way that was found to implement a layer of compatibility in the transition to > 2.2TiB hard disks.

This bug was introduced when you changed the start sector of disks larger than 2.2TiB to 64, and the verification routine remain expecting it to be 1. With the fix, now the correct partition size is set even if the disk is greater nan 2.2TiB and is precleared starting on sector 64. Tell me, is that blockdev -setro op really preventing changes in the MBR? PS: The verification step of the plugin obey the same logic of the original script, so it suffered the bug too.

Yep, that's it. I've committed the fix to binhex too, we should see an update soon.

Update the Preclear Plugin to version 2020.03.02 and test it again.

Apparently I found the bug. Please update your plugin to 2020.03.02 and test it again, please. If we validate the solution, I'll commit the fix to binhex repository.

That's not needed. You could test it using the plugin so we can see if it replicates on the other script? You can run the "Verify MBR Only" opoeration.

Which command you passed to preclear_binhex.sh?

Maybe you got a bad USB/SATA bridge controller. Try connecting it into the controller of another hard drive you've already shucked.

🤔 All in the same port? These are drives that you're planning to shuck?

All other drives were 14TB? Maybe a loose cable or a power brownout.

Yep, USB dropouts. You're not the first this week. If you can test the drive connected directly to a SATA port, we can troubleshoot it.

Yep

Send the diagnostics file.

Hi @jbrodriguez, any chance of implementing this?

@HDRW, your hard drive is ok, it's a problem with your USB dock, with it's connection cable or with your USB controller.