May 12, 20197 yr Hello, I just added new drive to my array, 8TB HGST he8. Before adding the new drives to expand the array, I added 2 8TB drives for the Parity but the build speed is super slow. My specs are i7 7700 12Gb Ram and an arrangement of RED + HGST He drives. Everything is plugged into the 6 SATA ports of my motherboard, no SAS card yet. I tried the SDPARM command : sdparm -g WCE /dev/sdf but I have a WCE not found error, maybe its because it's only for SAS drives? Then I installed the Turbowrite plugin as suggested here but the speed is not changed at all, exactly the same. Is there anything I can do ? Thanks unraid-diagnostics-20190512-1032.zip Edited May 12, 20197 yr by yendi
May 12, 20197 yr Author I get that but none of the disk has a read/write speed of ~50mb. The HGST where around 130mb/s (7200rpm) during the preclear, and the REDs average read/write are 100+ And I am talking about Parity initial build so it should be read speed of all disk from array --> write speed of HGST (Parity) I am not writing to the array like copying from my computer to the array... Edited May 12, 20197 yr by yendi
May 12, 20197 yr Writing to the array involves a four steps sequence, which will lower the overall write throughput. With RED disks an average write speed of 50Mb/s is expected.
May 12, 20197 yr Author But as my RED are only in storage and the HGST in Parity, as I am doing a Initial parity build, I am not writing on the REDs, right? As a matter of fact I only see read on the REDs and write on the HGST. Am I wrong?
May 12, 20197 yr Author I don't think this is the issue, I benchmarked it for 110mb/s in write speed, as all others REDs that I have. When I was copying from Windows to my array, I manage to get way better than 50mb/s without any cache
May 12, 20197 yr How far the parity rebuild? 10% means it is nearing the 1 TB border of disk2. At this point throughput of disk2 is already substantially lower than 110 Mb/s 20% means it is nearing the end of disk2. At this point performance of disk2 is at its lowest >25% disk2 is not involved anymore and write speed should go up
May 12, 20197 yr Author Ok I will leave it and see as it is only @ 2% (I cancelled it multiple times and ran some tests). I was thinking initially that there was something odd with the writing speed of the new drives in parity, not read speed. I will update this post when I pass the 25% mark. Total size: 8 TB Elapsed time: 1 hour, 6 minutes Current position: 203 GB (2.5 %) Estimated speed: 51.3 MB/sec Estimated finish: 1 day, 18 hours, 13 minutes Thanks
May 12, 20197 yr Write cache for parity disks is disabled, you can turn it on with: hdparm -W1 /dev/sdX Might go back to default after a reboot.
May 12, 20197 yr Author @johnnie.blackI have a command not found when I type it in Terminal, and can't find it in Nerdpack. Where can I install that tool from? Should I stop the rebuild first? Thanks
May 12, 20197 yr It's built in, make sure not to copy/paste as this forum sometimes inserts extra garbage.
May 12, 20197 yr 1 minute ago, yendi said: @johnnie.blackI have a command not found when I type it in Terminal, and can't find it in Nerdpack. Where can I install that tool from? Should I stop the rebuild first? Thanks hdparm is included in standard Unraid - you must have mistyped the command.
May 12, 20197 yr Author @johnnie.black You're the MVP !!! 137Mb/s Write speed!!! How can I make this permanent? Thank you so much !!!
May 12, 20197 yr Just now, yendi said: ow can I make this permanent? I'm not sure if it says on after a reboot, you'll need to try it. @limetechyou might want to enable write cache for any array drive at array start, this used to be an issue mostly for SAS devices but recently more and more SATA drives are the same.
May 12, 20197 yr Author Thank you, what command should I type to check the status after a reboot? hdparm -W /dev/sdX ?
May 12, 20197 yr 3 hours ago, ljm42 said: @Squid is this something Fix Common Problems could detect? Done. Can't test this on my system, but the code should catch what's listed in the OP's diagnostics - follows the rules on the avoid spinups (if avoidance is enabled, FCP won't run smartctl on the drive if its spundown). Let me know if any false positives and/or missed.
May 12, 20197 yr 23 minutes ago, Squid said: Done. Can't test this on my system, but the code should catch what's listed in the OP's diagnostics - follows the rules on the avoid spinups (if avoidance is enabled, FCP won't run smartctl on the drive if its spundown). Let me know if any false positives and/or missed. Very cool @Squid! FCP is awesome for this type of proactive notification No false positives here.
May 12, 20197 yr 8 minutes ago, ljm42 said: Very cool @Squid! FCP is awesome for this type of proactive notification No false positives here. I issued another quick update that should never have a false positive, (uses hdparm instead), and will catch (if it ever happens) that write-caching is disabled but smartctl doesn't show that fact. That I could test
May 13, 20197 yr 11 hours ago, Squid said: Done. That's great, can you also make sure it's detected for SAS devices? It uses sdparm which is now included with v6.7: https://forums.unraid.net/topic/72862-drive-write-speeds-really-slow-solved/
Archived
This topic is now archived and is closed to further replies.