I followed the steps at https://wiki.unraid.net/Shrink_array#The_.22Clear_Drive_Then_Remove_Drive.22_Method to remove an external drive I had attached so I could use it for other purposes.  Then I started a parity check.  However, after a minute of it running I have 2936958 sync errors.  I'm seeing nothing in my logs that should be causing that, or is it because I chose not to write changes to parity?  The steps don't say if you need to include that or not so I didn't use that option.

bb-8-diagnostics-20190411-1405.zip

Edited April 11, 20197 yr by shaunmccloud

Had you run a parity check (with 0 errors reported) before starting this process?   The whole idea of that method is to avoid breaking parity while removing the drive but it does rely on the parity being valid before you start.   Also if you got any step wrong then you would have ended up invalidating parity.

 

If you are getting any parity errors reported then either you have a hardware problem or you NEED to write the corrections to parity to get it back in sync with the drives you currently have in the array.   Once you have a done a correcting check the next check should always return 0 errors.

That would suggest the procedure wasn't done correctly, or there were already some sync errors from for example an unclean shutdown, if all looks OK run a correcting check.

23 minutes ago, johnnie.black said:

That would suggest the procedure wasn't done correctly, or there were already some sync errors from for example an unclean shutdown, if all looks OK run a correcting check.

Everything else looks ok, so I will run a correcting check (I've been very careful to avoid an unclean shutdown including running a 1400va APC UPS)

26 minutes ago, itimpi said:

Had you run a parity check (with 0 errors reported) before starting this process?   The whole idea of that method is to avoid breaking parity while removing the drive but it does rely on the parity being valid before you start.   Also if you got any step wrong then you would have ended up invalidating parity.

 

If you are getting any parity errors reported then either you have a hardware problem or you NEED to write the corrections to parity to get it back in sync with the drives you currently have in the array.   Once you have a done a correcting check the next check should always return 0 errors.

I had just finished a clean parity check before doing the procedure.  It is possible (probable) I did one step wrong.

Edited April 11, 20197 yr by shaunmccloud

The procedure if followed correctly would take a while to write zeros to the entire disk, before you could do anything else. How large was the disk and how long did it take to zero?

23 minutes ago, trurl said:

The procedure if followed correctly would take a while to write zeros to the entire disk, before you could do anything else. How large was the disk and how long did it take to zero?

2TB and I reformatted it instead of writing zeros, that could be why.

That wiki mentions format but only as one way to make sure the disk is empty before beginning the clear. The disk needs to be empty because the script won't let you clear a disk until you get the data off it. It looks like you may have skipped the most important stuff.

 

An empty disk isn't a clear disk. An empty disk has an empty filesystem, which represents an empty top level folder ready to receive files and folders. And formatting a disk doesn't really even change much of the data already on the disk. It just writes enough metadata to represent an empty filesystem. All that old data is still there but since it isn't part of the filesystem anymore it can't be normally accessed. All of that old data, and the empty filesystem, are part of parity and so can't be removed without invalidating parity.

 

A clear disk is full of nothing but zeros. It doesn't have a filesystem. When you clear a disk while it's in the parity array, parity is updated at the same time, so parity agrees the disk has nothing but zeros on it. It can be removed without invalidating parity because those zeros have no effect on parity.

3 minutes ago, trurl said:

That wiki mentions format but only as one way to make sure the disk is empty before beginning the clear. The disk needs to be empty because the script won't let you clear a disk until you get the data off it. It looks like you may have skipped the most important stuff.

 

An empty disk isn't a clear disk. An empty disk has an empty filesystem, which represents an empty top level folder ready to receive files and folders. And formatting a disk doesn't really even change much of the data already on the disk. It just writes enough metadata to represent an empty filesystem. All that old data is still there but since it isn't part of the filesystem anymore it can't be normally accessed. All of that old data, and the empty filesystem, are part of parity and so can't be removed without invalidating parity.

 

A clear disk is full of nothing but zeros. It doesn't have a filesystem. When you clear a disk while it's in the parity array, parity is updated at the same time, so parity agrees the disk has nothing but zeros on it. It can be removed without invalidating parity because those zeros have no effect on parity.

At any rate, parity is rebuilding and I learned something.  All is well.