Shrinking array

[t33j4y]

I am about to shrink my array as I want to phase out an older drive and have plenty of space as is. The drive contents have already been relocated using unBalance.

 

However, I am a bit uncertain about the process as I have seen a couple of different approaches.

 

Can someone who has followed this procedure:

 

https://lime-technology.com/wiki/Shrink_array#The_.22Clear_Drive_Then_Remove_Drive.22_Method

 

verify that this will in fact allow me to remove the drive without breaking parity? If it matters, I am running dual parity.

 

Thanks in advance for any input and advice!

 

BR,

 

Thomas

[JonathanM]

I would recommend not trying to keep parity whole. I personally don't think it's worth the effort, when you can rebuild parity in a few hours.

 

If it were me and I was being super paranoid about drive loss here is what I would do.

 

1. Run long smart tests on all drives

2. Parity check - 0 errors, if any errors, stop and evaluate

3. Collect diagnostics, evaluate for any errors - attach zip to forum post and ask for advice if you are unsure what to look for

4. New config - maintenance mode, assign ONLY parity 2 and desired end configuration for data drives, build parity 2

5. Parity check

6. Assign parity 1 and build

7. Parity check

 

If I was confident about the complete health of my server already, I would condense it down to 2 steps.

 

1. New config without the unwanted drive, build parity

2. Parity check

 

My 0.02, opinions vary, yada, yada.

[John_M]

6 minutes ago, jonathanm said:

1. Run long smart tests on all drives

2. Parity check - 0 errors, if any errors, stop and evaluate

 

Just out of curiosity, does a long SMART self-test usefully do anything that a parity check doesn't, apart from storing the result of the test in the disk's own firmware, which can be handy sometimes? I've been running a lot of both recently and it made me think.

[JonathanM]

1 hour ago, John_M said:

 

Just out of curiosity, does a long SMART self-test usefully do anything that a parity check doesn't, apart from storing the result of the test in the disk's own firmware, which can be handy sometimes? I've been running a lot of both recently and it made me think.

It verifies that all sectors are readable internally, isolating cabling and HBA errors as far as read errors are concerned. It's also a good followup to a successful rebuild, since parity builds or disk rebuilds are written without read verification. If a post rebuild parity check shows errors, and the long smart tests are all ok, it's a good clue where to start looking.

 

The logged timestamped entries in the firmware are a significant bonus, since they stay for the life of the drive.

[t33j4y]

jonathanm, thank you for your suggestion.

 

You mention that parity can be rebuilt in a few hours - am I missing something or is the parity rebuild not equal in duration to a parity check? If so, that's like 16 hours for me so the process you outline will take a long time with three parity checks across the seven steps. 

[trurl]

24 minutes ago, t33j4y said:

jonathanm, thank you for your suggestion.

 

You mention that parity can be rebuilt in a few hours - am I missing something or is the parity rebuild not equal in duration to a parity check? If so, that's like 16 hours for me so the process you outline will take a long time with three parity checks across the seven steps. 

 

The parity checks are just to confirm that all is good and all went well. They could have been recommended for the procedure you linked also. And the clear procedure will probably take longer than a parity build.

[t33j4y]

trurl, thanks. I guess I am gonna bite the bullet and get going. Have started the extended smart tests now :-)