Parity check correcting huge # of errors

[hades]

Running latest 6b14. I had a bunch of 3TB drives, and wanted to replace one of the failed 3TB drives with a 4TB drive I had available. Knowing that the 4tb would have to be the parity, I followed the swap-disable procedure, where I pulled the failed drive, left it missing, then reassigned the 3TB parity to be the missing, assigned the 4TB to be the new parity. Then started the array.

 

Parity was copied from 3TB to 4TB.

Old 3TB parity was rebuilt fine as the missing 3TB drive.

 

Now I'm running a Parity check, and it went fine up to the 3TB point. After the 3TB point (3TB is my largest data drive), I'm encountering a huge number of parity errors being written to disk.

 

Is there something wrong? My theory is that the 4TB drive contained 3TB parity information, and the remaining 1TB data was garbage, which now it is correcting. The log doesn't show anything wrong.  Thank you!

syslog.zip

[itimpi]

That does sound a little strange.  It is possible that your theory is right, but if the behaviour would be a bug as parity should have been written initially assuming that all space beyond the end of the current data drives was effectively zeroes.

[hades]

I'm not noticing any reads from any of the drives, but a large number of writes to the parity drive. The parity drive seems to be the only one active, and it is SLOW. 8.5MB/s. In the past, as the smaller drives were complete, the parity build/check became faster and faster.

 

I'll leave this running as is, then do another check immediately after.

 

Just do not wish this to blow up in my face. Thanks.

[itimpi]

Yes - I would definitely expect the parity to speed up once beyond the end of the data disks.

 

That very low speed is a bit worrying.  I would have expected the parity check to be running much faster at this point.  It is almost as if the system is having some sort of issue with the disk - but there did not seem to be anything in the syslog that suggests this.

[hades]

It's up to 66,435,555 corrections, and climbing. No errors in the log. Some random other disks spun up, but no activity. Parity "check" is going at 8.5mb/s.

 

Thanks.

[hades]

Just an update on this. The original parity-check corrected a huge number of errors, all beyond the 3TB limit of the original parity drive. After it finished, I started another parity-check. That completed with 0 errors. I'm assuming all is good.

 

Thank you,

 

hades

[itimpi]

Just an update on this. The original parity-check corrected a huge number of errors, all beyond the 3TB limit of the original parity drive. After it finished, I started another parity-check. That completed with 0 errors. I'm assuming all is good.

 

Thank you,

 

hades

That is strange - sounds as if originally something went wrong with creating the parity beyond the 3TB range that has now been rectified.  Still I guess the key thing is that the system now seems to be behaving as expected.

[trurl]

I'm not sure this is unexpected behaviour if you didn't preclear the new disk. The state of the disk beyond 3TB was unknown and would have incorrect parity. I don't think unRAID does the parity calculation/correction any different. Once it gets beyond the size of a data disk, that disks contribution to the calculation is zero. If none of the disks are as large as parity, then at that point the calculation is made with each of them considered zero at that point. If the new parity is not precleared, then parity at that point would need to be corrected.

[itimpi]

I'm not sure this is unexpected behaviour if you didn't preclear the new disk. The state of the disk beyond 3TB was unknown and would have incorrect parity. I don't think unRAID does the parity calculation/correction any different. Once it gets beyond the size of a data disk, that disks contribution to the calculation is zero. If none of the disks are as large as parity, then at that point the calculation is made with each of them considered zero at that point. If the new parity is not precleared, then parity at that point would need to be corrected.

Yes - but this was a parity check!

 

I would have expected the original parity creation to assume that space beyond 3TB on other drives was effectively zeroes and write the correct parity the first time around so that the check had nothing to do.  It sounds as if when creating the original parity unRAID did not complete the section beyond 3TB.  After all if at this point a new pre-cleared 4TB drive had been added without first doing the parity check the parity for the last 1TB would have been wrong.