Greetings,

I just started a parity sync this morning with a Seagate 8TB shingled drive.  All of my data drives are currently 4TB.  Once the sync reaches 4TB is it essentially done?  Or will it take just as long to zero the second 4TB of the parity drive as it did to calculate parity for the first 4TB?  I figure if it is the former, the sync will be done some time tonight. If it is the latter, the sync will not finish until tomorrow morning some time.

it will sync 8TB, second part can be a little faster if you have a controller bottleneck when reading all disks, from 4TB to 8TB should take about 8 or 9 hours.

Got it. Thanks.

So from what I've gathered the parity sync time depends on a number of factors, how many drives in your system, the controllers they are attached to and the sizes of the drives. For example, my backup server is currently running UnRaid 6.2b21 and I have 26 drives in my system, two 8TB Seagate shingled drives for parity, one 2TB WD Green for cache,  and 23 data drives. My parity syncs take anywhere from 27-30hrs. My system has nothing smaller than a 3TB drive, some 4TB, some 5TB and a few more 8TB drives. Sixteen of my drives are connected to an Areca raid controller running JBOD and the rest are either connected to the onboard SATA ports or PCIe sata controllers.

So from what I've gathered the parity sync time depends on a number of factors, how many drives in your system, the controllers they are attached to and the sizes of the drives. For example, my backup server is currently running UnRaid 6.2b21 and I have 26 drives in my system, two 8TB Seagate shingled drives for parity, one 2TB WD Green for cache,  and 23 data drives. My parity syncs take anywhere from 27-30hrs. My system has nothing smaller than a 3TB drive, some 4TB, some 5TB and a few more 8TB drives. Sixteen of my drives are connected to an Areca raid controller running JBOD and the rest are either connected to the onboard SATA ports or PCIe sata controllers.

 

Indeed. I had to get rid of my non-8TB drives when using 8TB parity, they made monthly parity checks far too slow. For example, my parity check with 2/3/4/8TB drives was estimated at roughly 2 days, removing everything but 4TB reds and 8TB archive drives was roughly 30 hours, and finally removing everything but the 8TB archive drives brought it down to reasonable 18 hours. If you have a mixture of even slower/smaller drives, especially drives of different platter sizes, I could see 8TB parity checks taking a few days on some systems.

 

Not good because data rebuilds also take far longer with slower drives in the system, which dramatically increases chances of additional failures resulting in data loss.

So from what I've gathered the parity sync time depends on a number of factors, how many drives in your system, the controllers they are attached to and the sizes of the drives.

 

Yes, all these are factors, two more common ones, the more different capacity disks you have the slower it will be and older disks with smaller platters are also considerably slower than more recent disks with bigger ones.

Is it slower because

• <8TB drive slow down the parity check simply because they are <8TB
  
• Your <8TB drives are just slower e.g.5400rpm
  
• Too many drives cause a bottleneck on the controller

[*]Other reasons?

 

I can't get my head around how mixing drive sizes would slow down the speed.

I can't get my head around how mixing drive sizes would slow down the speed.

 

That's how hard drives work. Bigger platter sizes scale fairly linearly in terms of speed. A 2TB platter will be roughly 2x faster than a 1TB platter spinning at the same speed. Drives are also faster at the start of platters, and dramatically slow down as they go on. So multiple drive sizes means not only are you bottlenecked by the slowest drive, but you'll always be bottlenecked by the slowest end of platters. If you had a mixture of 1/2/3/4/5/6/7/8TB drives in the same system, your parity checks would be days.

 

It's why this plugin exist:

https://lime-technology.com/forum/index.php?topic=31073.0

 

It allows you to pinpoint which drives are slowing down your system and by how much.

See the example below with 3 and 8tb disks, parity speed can't be faster than the slower disk, so as it's going trough the inner (slower) tracks of the 3TB disk it will be much slower than with all 8TB disks, speed will follow the red line, the more different sizes the slower it will be, because it slows down considerably at the end of each different size disk.

So looking at this, would the read not already have the same issue before adding in the 8tb drives, i.e. the system would already have been running at the slowest drive speed in these scenarios? I know the 8tb drive is larger and from what I am reading (correct me if I am wrong) the parity speed increases as it finishes reading each of the slower drives and so once it hits the drive either the same as 8tb as the parity or next smallest, it will be reading parity at that speed?
I know personally that parity on my 16 drives in my array it takes about 12 hours for a parity check with max drives at 4tb which is what I have in the main server (all 4tb drives). I am going to be adding two 8tb drives to my setup to open the way to start swapping out the 4tb drives as the 8tb gets cheaper, so it will be interesting to see how much longer the parity check will take (I will obviously have to build it first after the swap out).

I've been running the 8TB drive for almost a year now so I don't remember exactly what happened. But if memory serves me, the parity rebuild did need to write to the entirety of the 8TB drive, but once it got past the initial 4TB of all the other drives the speed increased significantly as there wasn't really anything for it to calculate and it just need to ensure that 0's were written to the remainder of the drive. 

johnnie.black pretty much explained above what happens with different sized disks. The reason disks are slower on the inner tracks is simply because the inner tracks are shorter in circumference than the outer tracks. Because they are shorter, the inner tracks actually hold less data. So less data read per rotation of the disk.