While my array consists of 4TB disks, I bought a 8TB disk to use as parity drive, so I won't have to juggle everything around if I'd buy a larger data disk in the future. When the parity check is running one would think it would be enough to just check the area up to the size of the largest data drive, but it always does the full 8TB which of course takes twice the time.

 

Anyone knows if there's a reason for this?

 

To ensure parity integrity is 100% complete.

Suppose a larger data disk is added later, the system needs to rely on valid parity for the "new" area.

46 minutes ago, bonienl said:

To ensure parity integrity is 100% complete.

Suppose a larger data disk is added later, the system needs to rely on valid parity for the "new" area.

Perhaps I'm thinking wrong here, but the "new" area wouldn't have any parity since it's calculated at writes. At least zeroing the parity disk at installation ought to remove the need to check this unused space allt he time.

A parity is done to ensure everything is still correct (no assumptions), even when there are zeroes.

52 minutes ago, bonienl said:

A parity is done to ensure everything is still correct (no assumptions), even when there are zeroes.

So, in that >4GB space, what's the parity going to be compared to? There's no other data to perform a checksum with. "Let's see, I take the bit from this disk, and XOR it with..., well nothing at all, and then see if it's still the same value"?

 

If you do checksum on the unused space, and for some reason a zero have turned into a one, a parity check won't catch that anyway, because 1 XOR nothing is still 1.

Edit: Ok, the check is probably this way and then it'll put zeroes on the extra space:

    Start with zero, for each data disk, XOR the value, then compare/update to the parity disk.

 

Sorry for being stubborn. It's no biggie really, but I still can't grasp the reason and it bugs me.

Edited October 1, 20196 yr by Ancan