I now have 2 Empty PATA drives (the only PATA in my system) that I'd like to remove... I have good Parity from a few days ago.

 

I've followed this Wiki post in the past to remove a single, empty, non-immediately replaced drive in the past.  But I'd like to pull out both of the PATA's at once to prevent having to rebuild Parity twice (which each is a multiple day process until I replace my PCIe SATA Card....)  I am running 5.0b6a

 

http://lime-technology.com/wiki/index.php?title=FAQ#How_do_I_remove_a_hard_disk_that_I_do_not_plan_on_replacing.3F

You can remove any number of disks, reset the disk configuration, and rebuild parity. Don't have to do it one at a time.

 

There are some more creative ways too. If you do a binary copy of one of the empty disks to the other (assuming they are the same size, you can remove both and then run the trust my parity procedure without a parity build.

You can remove any number of disks, reset the disk configuration, and rebuild parity. Don't have to do it one at a time.

 

There are some more creative ways too. If you do a binary copy of one of the empty disks to the other (assuming they are the same size, you can remove both and then run the trust my parity procedure without a parity build.

 

Thanks... I don't mind doing another single Parity Check, I just didn't want to have to do 2... Hopefully my Breakout Cables will be here today, so I can install the new SASLP card before removing PATA drives.

You can remove any number of disks, reset the disk configuration, and rebuild parity. Don't have to do it one at a time.

 

There are some more creative ways too. If you do a binary copy of one of the empty disks to the other (assuming they are the same size, you can remove both and then run the trust my parity procedure without a parity build.

 

Thanks... I don't mind doing another single Parity Check, I just didn't want to have to do 2... Hopefully my Breakout Cables will be here today, so I can install the new SASLP card before removing PATA drives.

 

Parity check and parity build are different.

 

Parity check just verifies parity is correct (it runs in CORRECT and NOCORRECT modes, depending on your pleasure).  Your array continues to be protected during a parity check.

 

Parity build (also called a Parity Sync) writes parity info to your parity disk.  No verifying is done - just writing.  Your array is NOT protected until the parity build completes.  And the parity build is considerably slower than a parity check.  A parity build should always be followed by a parity check to ensure that parity build is good.

 

To remove a disk, you normally have to do a parity build (recommend followed with a parity check).  The trick I communicated avoids the build (although a parity check is still recommended).  It does require a complete rewrite of one of the PATA drives while in the array, which might be faster or slower than a parity build depending on its size and speed.  The real benefit is that you maintain parity protection and are therefore always able to recover from a disk failure.

You can remove any number of disks, reset the disk configuration, and rebuild parity. Don't have to do it one at a time.

 

There are some more creative ways too. If you do a binary copy of one of the empty disks to the other (assuming they are the same size, you can remove both and then run the trust my parity procedure without a parity build.

 

Thanks... I don't mind doing another single Parity Check, I just didn't want to have to do 2... Hopefully my Breakout Cables will be here today, so I can install the new SASLP card before removing PATA drives.

 

Parity check and parity build are different.

 

Parity check just verifies parity is correct (it runs in CORRECT and NOCORRECT modes, depending on your pleasure).  Your array continues to be protected during a parity check.

 

Parity build (also called a Parity Sync) writes parity info to your parity disk.  No verifying is done - just writing.  Your array is NOT protected until the parity build completes.  And the parity build is considerably slower than a parity check.  A parity build should always be followed by a parity check to ensure that parity build is good.

 

To remove a disk, you normally have to do a parity build (recommend followed with a parity check).  The trick I communicated avoids the build (although a parity check is still recommended).  It does require a complete rewrite of one of the PATA drives while in the array, which might be faster or slower than a parity build depending on its size and speed.  The real benefit is that you maintain parity protection and are therefore always able to recover from a disk failure.

 

Ok...   ???  I think I'm too dumb to be a UnRaid user... I'm just a GUI button pusher... Bill Gates has ruined me.

Will try to explain.  I think it is helpful to have an understanding of how parity works.

 

Say this is your array - a whole 8 bits.  Disks 5 and 6 are your PATA drives you want to remove (in the diagram below, the far left column shows the disk numbers and P for parity at the bottom.  Each of the 0/1 values to the right of the disk numbers shows the drive values in binary (1s and 0s)).

1-1 1 0 1 1 0 0 1
2-0 0 0 1 1 0 1 0
3-1 1 0 0 1 1 0 0
4-1 0 1 0 1 1 0 1
5-0 1 0 0 0 1 0 0
6-0 0 0 1 0 1 1 0
P-1 1 1 1 0 0 0 0

Notice that each column adds up to an even number.  unRAID computes and maintains parity so that is always true.  If the number of ones for all the numbered disks is odd, parity is "1".  If the number of ones for all of the numbered disks is even, parity is "0".  This is the basis of parity protection.

So if you want to pull disks 5 and 6, parity would be wrong (the x's show the wrong parity caclulations).

1-1 1 0 1 1 0 0 1
2-0 0 0 1 1 0 1 0
3-1 1 0 0 1 1 0 0
4-1 0 1 0 1 1 0 1
P-1 1 1 1 0 0 0 0
   x   x     x

In order to make parity correct, you'd have to rebuild it (below shows correct parity after it is rebuilt).

1-1 1 0 1 1 0 0 1
2-0 0 0 1 1 0 1 0
3-1 1 0 0 1 1 0 0
4-1 0 1 0 1 1 0 1
P-1 0 1 0 0 0 1 0

But what if disk4 were to fail as you were rebuilding parity ...

1-1 1 0 1 1 0 0 1
2-0 0 0 1 1 0 1 0
3-1 1 0 0 1 1 0 0
4-1 0 1 0 1 x x x
P-1 0 1 0 0 ? ? ?

unRAID would not be able to continue building parity, and it would have no way to know the last values of disk 4.  You would lose data on disk4.

So lets start over.  Instead of removing disks 5 and 6, instead we copied disk 5 to disk 6 - not just the files but every bit cloned precisely.  As disk 6 is updated, parity is updated to maintain the even parity.

1-1 1 0 1 1 0 0 1
2-0 0 0 1 1 0 1 0
3-1 1 0 0 1 1 0 0
4-1 0 1 0 1 1 0 1
5-0 1 0 0 0 1 0 0
6-0 1 0 0 0 1 0 0 <- disk 6 is being updated to be a clone of disk5
P-1 0 1 0 0 0 1 0 <- parity is being updated as a result

And look what would happen if we removed disks 5 and 6 together ...

1-1 1 0 1 1 0 0 1
2-0 0 0 1 1 0 1 0
3-1 1 0 0 1 1 0 0
4-1 0 1 0 1 1 0 1
P-1 0 1 0 0 0 1 0

Wow, look at that.  Parity is still perfect!  Why, because 2 identical drives cancel each other out.  The sum of their bits is always even (0+0 and 1+1 are both even).

So by cloning disk 5 onto disk 6 (or vice versa), you have, in effect, made the two drives invisible from a parity perspective.  If you remove them both together, parity is still corrrect.

And parity was maintained throughout, so if a disk were to fail:

1-1 1 0 1 1 0 0 1
2-0 0 0 1 1 0 1 0
3-1 1 0 0 1 1 0 0
4-1 0 1 0 1 x x x
P-1 0 1 0 0 0 1 0

unRAID could simulate or rebuild it ...

4-1 0 1 0 1 1 0 1

[b]UPDATE:  Although parity is perfect, unRAID will have no way of knowing that parity is perfect.  If you simply remove the 2 disks, unRAID will refuse to start the array.  You would need to use "trust my array" procedure outlined in the link below to "tell" unRAID that your array has a valid parity.[/b]

With the trust my array procedure, you can make unRAID trust your array even after you remove disks.  It is explained in the wiki [url=http://lime-technology.com/wiki/index.php?title=Make_unRAID_Trust_the_Parity_Drive,_Avoid_Rebuilding_Parity_Unnecessarily]HERE[/url].

 

Hope this makes more sense.  If not let me knoow and I'll keep trying.  Will get you out of GUI mode one way or another!

Yes, I get this example a little better, but I probably couldn't explain it to someone else intelligently.    What I don't have a clue about is the steps on how I make that clone of the one disk to the other and or the commands that would be required to take it from that point, to turning off the server, unplugging the drives, restarting the server and then restarting the array.  Since I have another 10 hours for the Parity Sync from me shuffling my SATA Card around, it won't matter until tomorrow.