April 2, 20188 yr It wouldnt bother me if it didnt lock up the array where i can not access my files but this is getting ridiculous with the new 8tb drives i put in.... 2018-04-02, 08:32:25 1 day, 8 hr, 32 min, 24 sec Unavailable Canceled 0 2018-03-24, 01:21:08 1 day, 19 hr, 8 min, 41 sec 51.5 MB/s OK 0 Model: Custom M/B: Supermicro - H8DM8-2 CPU: Six-Core AMD Opteron™ 2419 EE @ 1800 HVM: Enabled IOMMU: Disabled Cache: 768 kB, 3072 kB, 6144 kB Memory: 32 GB Single-bit ECC (max. installable capacity 32 GB)* Network: bond0: adaptive load balancing, mtu 1500 eth0: 1000 Mb/s, full duplex, mtu 1500 eth1: 1000 Mb/s, full duplex, mtu 1500 Kernel: Linux 4.14.26-unRAID x86_64 OpenSSL: 1.0.2n I mean i feel like my options are: A; build a new server with faster CPU's B: dont use parity check C: dont use the array for 2 days each month. tower-diagnostics-20180402-0836.zip Edited April 2, 20188 yr by pyrater
April 2, 20188 yr Community Expert 37 minutes ago, pyrater said: I mean i feel like my options are: Basically, I vote for option A
April 2, 20188 yr I must admit, with the growing size of disks the parity check is becoming an issue. On my system, which has a mixture of 4tb, 6tb and 8tb disks the parity check is taking around 27 hours. When I buy another disk I would like to go to 12tb disks .... but a possibility of a 50% increase in parity check time is a bit worrying. There has previously been a suggestion of allowing parity checks to be split into multiple runs so that it could be completed over a number shorter runs on different days. With the ever increasing size of disks this is becoming more and more of an issue.
April 2, 20188 yr Author This solution will hopefully make it to @limetech 's Road map. Along with multi threaded parity check for us that are CPU limited.
April 2, 20188 yr 45 minutes ago, pyrater said: I mean i feel like my options are: A; build a new server with faster CPU's B: dont use parity check C: dont use the array for 2 days each month. Another option (you would have to test) would be to go down to only a single parity drive as the CPU might not be up to the task of the extra calculations for dual.
April 2, 20188 yr Community Expert 1 minute ago, remotevisitor said: On my system, which has a mixture of 4tb, 6tb and 8tb disks the parity check is taking around 27 hours. Having multiple size disks is one of the big advantages of unRAID, but it doesn't help with parity check speeds, still 27H is a lot for those sizes, since a 8TB array only can do it in 15H. I try to keep my mains servers limited to a single disk size, and my backup servers to 2 different size tops, to keep parity checks and rebuilds as quick as possible.
April 2, 20188 yr Author 4 minutes ago, Squid said: Another option (you would have to test) would be to go down to only a single parity drive as the CPU might not be up to the task of the extra calculations for dual. yea i could try that but with 17 disks i really want the dual parity lol Note: my backup server is all 8 tb drives (single parity) , with a faster cpu setup and completes the check in 1/2 to 1/3 the time.... 2018-04-01, 19:56:20 18 hr, 56 min, 19 sec 117.4 MB/s OK 0 2018-03-30, 23:49:49 17 hr, 15 sec 130.7 MB/s OK 0 Edited April 2, 20188 yr by pyrater
April 2, 20188 yr Is the bottleneck with the CPUs or with the PCI-X based HBAs though? If I've read it correctly your motherboard has two PCIe x8 slots. How about using them for a pair of Dell H310s and moving to fewer but bigger disks?
January 27, 20197 yr Author Just an update: i have 2 LSI cards installed now, it didnt fix the speed. It is still 48 MBs. It has to be CPU bound i think. Edited January 27, 20197 yr by pyrater
Archived
This topic is now archived and is closed to further replies.