First time unraid user here. I have a 4-disk array configured with 1 parity drive and 3 data drives. All drives are new.

 

Why is the parity sync slow? Surely the system knows the drives are all empty (they aren't even formatted yet, so clearly there's no data). Is there a way to manually override the default and just say "it's all good, the parity drive should just be zeroed"?

Unless you actually zeroed the data drives, parity should not be zeroed. 

And zeroing parity would not be very fast anyway since all of the disk has to be written. 

I think zeroing 16Tb can happen faster than 13 days.

 

So the answer here is: it’s a user error and I should have known to create and format the data drives first and then the parity sync would have done the right thing?

 

I have to say I’m underwhelmed by the user friendliness of Unraid. Why not provide a happy path wizard for new arrays? Or at least write down the recommended steps. This way I’m spending half of my trial period waiting for a sync that isn’t needed. 

13 hours ago, dvdplm said:

I think zeroing 16Tb can happen faster than 13 days.

That's not normal, it should be around 1 day, please post the diagnostics during a sync.

Here goes, thank you.

minispalm-ur-diagnostics-20240516-0859.zip

May 14 07:22:58 minispalm-ur kernel: sd 1:0:5:0: Power-on or device reset occurred
May 14 07:23:00 minispalm-ur kernel: mpt2sas_cm0: log_info(0x31120311): originator(PL), code(0x12), sub_code(0x0311)
### [PREVIOUS LINE REPEATED 9 TIMES] ###
May 14 07:23:00 minispalm-ur kernel: sd 1:0:1:0: Power-on or device reset occurred
May 14 07:23:00 minispalm-ur kernel: sd 1:0:5:0: Power-on or device reset occurred
May 14 07:23:00 minispalm-ur kernel: sd 1:0:1:0: Power-on or device reset occurred
May 14 07:23:02 minispalm-ur kernel: mpt2sas_cm0: log_info(0x31120311): originator(PL), code(0x12), sub_code(0x0311)
### [PREVIOUS LINE REPEATED 10 TIMES] ###
May 14 07:23:02 minispalm-ur kernel: sd 1:0:1:0: Power-on or device reset occurred
May 14 07:23:03 minispalm-ur kernel: mpt2sas_cm0: log_info(0x31120311): originator(PL), code(0x12), sub_code(0x0311)
### [PREVIOUS LINE REPEATED 4 TIMES] ###
May 14 07:23:03 minispalm-ur kernel: sd 1:0:4:0: Power-on or device reset occurred
May 14 07:23:04 minispalm-ur kernel: sd 1:0:1:0: Power-on or device reset occurred
May 14 07:23:04 minispalm-ur kernel: sd 1:0:4:0: Power-on or device reset occurred

May 14 07:24:39 minispalm-ur kernel: I/O error, dev sdd, sector 17958480 op 0x0:(READ) flags 0x0 phys_seg 68 prio class 2
May 14 07:24:39 minispalm-ur kernel: md: disk2 read error, sector=17958416
May 14 07:24:39 minispalm-ur kernel: md: disk2 read error, sector=17958424
May 14 07:24:39 minispalm-ur kernel: md: disk2 read error, sector=17958432
May 14 07:24:39 minispalm-ur kernel: md: disk2 read error, sector=17958440
May 14 07:24:39 minispalm-ur kernel: md: disk2 read error, sector=17958448
May 14 07:24:39 minispalm-ur kernel: md: disk2 read error, sector=17958456
May 14 07:24:39 minispalm-ur kernel: md: disk2 read error, sector=17958464
May 14 07:24:39 minispalm-ur kernel: md: disk2 read error, sector=17958472
May 14 07:24:39 minispalm-ur kernel: md: disk2 read error, sector=17958480
May 14 07:24:39 minispalm-ur kernel: md: disk2 read error, sector=17958488
May 14 07:24:39 minispalm-ur kernel: md: disk2 read error, sector=17958496
May 14 07:24:39 minispalm-ur kernel: md: disk2 read error, sector=17958504

 

Issues with multiple disks, but worse with disk2, this usually means a power/connection issue, check/replace both cables.

Ok, something's clearly wrong on my side. I pulled out one of the disks (disk2) and waited for a while and plugged it back in. While the disk was out the parity sync speed went way up (~120Mb/s, so ~10x faster) and it kept going at a decent pace when I plugged the disk back in.

 

I ordered a new SFF-8088 cable to see if that makes any difference for the error rate. Tyvm for the help so far.