Probably a noob mistake, but when you don't do it that often...

 

Anyway, I thought I followed all of the procedures correctly, but I think I messed up by keeping both parity drive in while I rebuilt parity. I went from a 2 TB drive to a 3 TB drive for parity. Now when I disable the original drive that was used for parity, the system says all is good, but my main dashboard, for drives, it lists "parity 2" as the first device.  Is there a way to change this to be "parity".  And may be a brief explanation of what step I messed up on?

 

Thanks!

Others may understand better, but it wasn't clear to me what you did.  Can you elaborate the steps you took?  And please read Need help? Read me first!, and attach the diagnostics zip.

I think what you are saying is that you assumed the two parity slots were equivalent. They are not. The math used to generate P1 is simple, the same math that's always been used since unraid's inception. The math for P2, however, is way more complex, and not at all interchangeable with P1. It can be used in the same way, to rebuild a single failed drive, so you are still protected from failure to the same degree, but you can't interchange P1 and P2.

 

You didn't mess up, you are fine leaving it as is.

... You didn't mess up, you are fine leaving it as is.

 

Essentially true, but there is one notable difference ...

 

With only a P2 drive, the disk positions are important -- i.e. you can't move disks to different slots and still have valid parity.  That's also true if you have dual parity (since one of those will be P2).    With single parity using the "original" calculation (P1) you can freely change the disk slots without impacting the validity of parity.

 

Sounds like instead of rebuilding parity(1), you added parity2 then removed parity(1). Is that what you did?

 

Definitely not the correct procedure for replacing parity(1) with a larger drive. What procedure exactly were you following? Do you have a link?

Ok - Sorry I was in a hurry last night and I neglected all of the other stuff.

 

So, the reasons and steps that I took:

 

I obtained 4 new 3TB HDs. My system currently has / had

 

Parity = 2TB

Disk 1 = 2 TB

Disk 2 = 0.5TB

Disk 3 = 0.5TB

Disk 4 = 2TB

Disk 5 = 2TB

 

I followed the steps laid out by bjp999 here: http://lime-technology.com/forum/index.php?topic=33277.msg306300#msg306300

 

which are:

 

I like the way you think! Great question!

 

0. If the new parity disk is brand new or has never been tested, do a preclear on it.

 

1. Take smart reports of all drives. Look for reallocated sectors and pending sectors or anything that says failing now. If you haven't already, you might consider installing unmenu and bringing up the myMain smart view (see my sig). It will run the smart reports for you and highlight anything it detects as concerning. Ask on the forums if questions about smart issues.

 

2. Do a parity check on the existing array. A parity check creates about the same level of stress as the parity build.

 

3. Do the smart reports again and compare if anything important got dramatically worse. For example, if your first check had 4 reallocated sectors, and after that disk had 316 reallocated sectors, I'd be worried about that disk!

 

4. If all is good, stop the array and make a backup of the config directory of your USB stick.

 

5. Note the placement of all the disks and what slots they are assigned to.

 

6. Do a new configuration, and assign the new parity, all data disks to their respective slots. And assign the current parity to the next data slot (if you intend to use it as a data drive).

 

7. Start the array. Let parity build. Do not format the unformatted old parity disk. Do not write to the array.

 

8. Should something go wrong like a red ball, save the syslog, stop the array, shutdown the server, fix loose connection (often the cause of the red ball), restore the USB (config directory) backup, and reboot. The old parity will be back in its prior place and the red ball will likely be gone. Run a parity check. You may get a few sync errors early. It's ok. Go back to step 3. Or ask for advice on the forum if drive red balls again.

 

9. If all goes well with the build do a parity check.

 

My problem was that when I got to step six, unRaid said invalid configuration and it would not let me restart the array. The only way I could do it was to put the original drive back in for Parity and then the new 3TB drive became parity2.  Then I built parity. When I deactivated parity(1) the system said all was fine, but now in reading the replies I'm pretty sure I want the original means of parity calculation.

 

So, now my question(s) are:

 

Can I just do another parity check with the original drive deactivated and with the new drive alone as parity? Will it then be made "parity" or would it always say parity2 even though it's calculated using parity(1) methods? Or should I put the original parity back in do another pre-clear on the new drive and try it all over again? If I do that why did unRaid say my configuration was invalid and not allow me to restart the array to rebuild parity? Did I miss a step? Did I really have to assign the old drive to another slot before trying to restart the array? Is that what I missed? (I wanted to not risk the parity drive yet.)

 

Thanks for all of your helps.

 

madison-diagnostics-20161228-0916.zip

Ok - Sorry I was in a hurry last night and I neglected all of the other stuff.

 

So, the reasons and steps that I took:

 

I obtained 4 new 3TB HDs. My system currently has / had

 

Parity = 2TB

Disk 1 = 2 TB

Disk 2 = 0.5TB

Disk 3 = 0.5TB

Disk 4 = 2TB

Disk 5 = 2TB

 

I followed the steps laid out by bjp999 here: http://lime-technology.com/forum/index.php?topic=33277.msg306300#msg306300

 

which are:

 

I like the way you think! Great question!

 

0. If the new parity disk is brand new or has never been tested, do a preclear on it.

 

1. Take smart reports of all drives. Look for reallocated sectors and pending sectors or anything that says failing now. If you haven't already, you might consider installing unmenu and bringing up the myMain smart view (see my sig). It will run the smart reports for you and highlight anything it detects as concerning. Ask on the forums if questions about smart issues.

 

2. Do a parity check on the existing array. A parity check creates about the same level of stress as the parity build.

 

3. Do the smart reports again and compare if anything important got dramatically worse. For example, if your first check had 4 reallocated sectors, and after that disk had 316 reallocated sectors, I'd be worried about that disk!

 

4. If all is good, stop the array and make a backup of the config directory of your USB stick.

 

5. Note the placement of all the disks and what slots they are assigned to.

 

6. Do a new configuration, and assign the new parity, all data disks to their respective slots. And assign the current parity to the next data slot (if you intend to use it as a data drive).

 

7. Start the array. Let parity build. Do not format the unformatted old parity disk. Do not write to the array.

 

8. Should something go wrong like a red ball, save the syslog, stop the array, shutdown the server, fix loose connection (often the cause of the red ball), restore the USB (config directory) backup, and reboot. The old parity will be back in its prior place and the red ball will likely be gone. Run a parity check. You may get a few sync errors early. It's ok. Go back to step 3. Or ask for advice on the forum if drive red balls again.

 

9. If all goes well with the build do a parity check.

 

My problem was that when I got to step six, unRaid said invalid configuration and it would not let me restart the array. The only way I could do it was to put the original drive back in for Parity and then the new 3TB drive became parity2.  Then I built parity. When I deactivated parity(1) the system said all was fine, but now in reading the replies I'm pretty sure I want the original means of parity calculation.

 

So, now my question(s) are:

 

Can I just do another parity check with the original drive deactivated and with the new drive alone as parity? Will it then be made "parity" or would it always say parity2 even though it's calculated using parity(1) methods? Or should I put the original parity back in do another pre-clear on the new drive and try it all over again? If I do that why did unRaid say my configuration was invalid and not allow me to restart the array to rebuild parity? Did I miss a step? Did I really have to assign the old drive to another slot before trying to restart the array? Is that what I missed? (I wanted to not risk the parity drive yet.)

 

Thanks for all of your helps.

That post you linked is 2.5 years old and was for V5. Nevertheless it would have probably worked except you apparently misunderstood step 6 and didn't set a new configuration, so instead it told you invalid configuration.

 

And you must have assigned the new parity drive to parity2 yourself, it wouldn't "become" parity2.

 

Do you want to use the old parity drive as a new data drive? If so, just start at step 6 again. You set a new configuration by going to Tools - New Config and assigning the drives to the slots you want them to be in. Depending on the specific V6 version you are running it may let you keep some of the configuration as is and only change the ones you want changed. Try it and post a screenshot if you have questions.

Agree -- you clearly did NOT do a "New Config"

 

But as trurl noted, all you have to do to "correct" it if you want your new parity to be the normal parity #1 is just do one now.

 

But as jonathanm noted earlier, you really don't have to do anything -- your system is fine.  You simply have a parity drive that uses the "parity2" algorithm.

 

The more you tinker with it, the more likely you are to mess up and lose data. Please be sure that any valuable data on the array exists on at least one other place, unraid parity is not a replacement for backups.

Agree => if you're not CERTAIN of what you're doing, then it's best to not do it 

 

And "correcting" your mistake is NOT, as already noted, really necessary -- the end result will provide exactly the same level of protection you have now ... AND you'll be "running at risk" (i.e. unprotected) for the duration of the new parity check.

 

I haven't written anything new to the array and I do want it to be right.  Otherwise, what's the point in doing anything. I realize it'd fine as it is, but...  That is the part that I messed up on...  creating a new config.

 

So, I want to do it again. Can I just start from step 6 and create the new config or should I pre-clear the new parity drive again?

 

Thanks for all of your help and advice.

 

I haven't written anything new to the array and I do want it to be right.  Otherwise, what's the point in doing anything. I realize it'd fine as it is, but...  That is the part that I messed up on...  creating a new config.

 

So, I want to do it again. Can I just start from step 6 and create the new config or should I pre-clear the new parity drive again?

 

Thanks for all of your help and advice.

No point in clearing the disk since it is going to be completely overwritten with parity anyway. A disk is only required to be clear when adding it to a new data slot in the parity array. This is so parity will remain valid. Preclear can also used to test a disk so unless you want to test it some more no point in clearing it.

Just to be absolutely SAFE in terms of not losing parity while there are any issues in the array, I'd do it this way ...

 

(a)  Do a parity check and confirm there are no errors (no disk errors and no sync errors)

 

(b)  Now do a New Config, and assign the disks as you want => be sure the parity disk is assigned to the first parity slot ... NOT to parity 2.

 

©  Then just Start the array and let it do the parity sync.  When that finishes, you should run a parity check to confirm all went well.

 

Done 

Just proceed from step 6. Step 7 tells you not to format the old parity drive, so if you take that advice and there is a problem, you can always get back to your original configuration with valid parity since that drive will still have parity on it.

 

In any case, if you are following the advice also in step 7 to not write anything to the array, then none of this should have any effect on your data disks, which should show no writes during this.

Success!!!  I now have a single parity drive again at 3TB. All of the other original drives are stable and the old parity drive has been added to the array as a new storage device.  Now when I get some more power splitters for the additional HDs, I will be adding on three more 3TB HDs for a total space of 18TB!!.  I do have a new, somewhat related question and if you say start a new thread I will do that. In my new array, I would have two 500GB HDs, four 2TB HDs and three 3TB HDs. For the two 500GB HDs, I'm considering just removing them because they take up two slots hardware wise and my case is getting low.  Can anyone point me to a procedure, or outline it here that would allow me to move the data on the two 500GB HDs to one of the new 3TB HDs, then just remove them without too much disruption? 

 

Thanks!!

Success!!!  I now have a single parity drive again at 3TB. All of the other original drives are stable and the old parity drive has been added to the array as a new storage device.  Now when I get some more power splitters for the additional HDs, I will be adding on three more 3TB HDs for a total space of 18TB!!.  I do have a new, somewhat related question and if you say start a new thread I will do that. In my new array, I would have two 500GB HDs, four 2TB HDs and three 3TB HDs. For the two 500GB HDs, I'm considering just removing them because they take up two slots hardware wise and my case is getting low.  Can anyone point me to a procedure, or outline it here that would allow me to move the data on the two 500GB HDs to one of the new 3TB HDs, then just remove them without too much disruption? 

 

Thanks!!

Instead of adding the new drives, use some of them to replace the small drives, thus rebuilding the small drives contents onto the new larger drives. You must do the replace and rebuild one at a time. Remove a 500GB and replace it with a new 3TB, then assign the new 3TB to the slot of the removed drive. Start will begin rebuild. Repeat for other drive.

Awesome - Yup that's an approach that I hadn't considered.

 

Just remember, format is NEVER part of the procedure for rebuilding a data disk. I don't know how, but some people have managed to do this, thinking somehow that you must format a disk in order to use it. Format means "write an empty filesystem", not what you want to do if you are rebuilding data.

Doing a rebuild is a good approach -- but if you've moved all these drives from an earlier version of UnRAID to v6, there's one other thing to consider => the file system.

 

If your drives are all Reiser FS, you may want to consider using XFS for all new drives.  Unless you've changed it, this is the default for v6 (it's trivial to change it -- Settings - Disk Settings - Default File System).    If you ADD A disk, it will be formatted XFS;  if you replace a disk and do a rebuild, it will be whatever file system was used on the old disk.

 

If you want the new disks in XFS, there are two ways to do that easily:

 

1.  You could simply add ONE of the 3TB drives to the system; then copy all of your data from the 500GB drives to that drive; and then do a New Config [now that you know how to do it  ] that does not include the 500GB drives.  Then Start the array and let it do a new parity sync.    This is very easy, but does run "at risk" (i.e. not fault tolerant) during the new parity sync.  You can then add the other 3TB drives at your leisure.

 

 

2.  If you want to maintain full fault tolerance during the entire process, you can do the following:

 

  (a)  Add ONE of the 3TB drives to the system, and copy all of your data from the 500GB drives to that drive.

 

  (b)  Delete all of the files from the two 500GB drives.

 

  ©  Replace one of the 500GB drives with a 3TB drive and let the system do the rebuild; 

 

  (d)  Replace the other 500GB drive with your 3rd 3TB drive and let the system do a rebuild; 

 

Note:  At this point you have all 3 of your 3TB drives in the system, with one in XFS format and containing all the data from the 2  500GB drives, and the other 2 empty but in Reiser format; 

 

  (e)  Stop the array; go to the Main tab; and , one-at-a-time, click on the disk# for the new 3TB drives and change the File System Type to XFS  (this will destroy any data currently on them and reformat them when you next Start the array -- but since they're empty that's no big deal); 

 

  (f) Start the array ... it will warn you that it's going to format the drives you changed the file system on ... and a couple minutes later you'll be done 

 

... it's obvious, but just to be sure:  If the 500GB drives are already XFS, then you can simply do the rebuilds ... no need to copy the data off, etc.    And you'll be fully fault-tolerant for the entire process (just like the 2nd process above).

The system was just built last year, so it is version 6 (6.2.4) and all drives are xfs.

 

So, if I just put one of the 3TB HDs in in place of one of the 500GB, I don't have to do format or anything? Is it a correct assumption then that the file system is "rebuilt" as part of the rebuild and once that's on the drive it's all set?

 

 

 

 

The system was just built last year, so it is version 6 (6.2.4) and all drives are xfs.

 

So, if I just put one of the 3TB HDs in in place of one of the 500GB, I don't have to do format or anything? Is it a correct assumption then that the file system is "rebuilt" as part of the rebuild and once that's on the drive it's all set?

Yes, that is correct. The rebuild is bit-for-bit, and the filesystem is just part of the bits.

 

As I mentioned, you MUST NOT do format. In fact, unRAID should not offer to format anything if you do the replacement correctly.

 

Not sure how, but some people have managed to format the disk when they replace it, and so they end up with an empty filesystem. Format means "write an empty filesystem to this disk". That is what it has always meant in every operating system you have ever used. unRAID treats this write just like any other, by updating parity. So after the format parity agrees that you have an empty filesystem and if you rebuild an empty filesytem from parity you get an empty filesystem.

ok.  I'll keep an eye out and make sure to NOT format.  I'll report any issues or oh oh's.

 

It's not strictly necessary, but for consistency (i.e. using the same approach on all versions), I'd do the replacements as follows:

 

(a)  Stop the array and unassign the drive you want to replace (e.g. one of the 500GB drives)

 

(b)  Start the array so it shows a "missing" disk

 

©  Stop the array and assign the new drive to the "missing" slot.    [You may have to shut down and change the drives before you can do this if you don't have all drives already in the system and attached to SATA ports.]

 

(d)  Start the array and let the system do the rebuild.

 

(e)  Optional, but a good idea => Do a parity check to confirm the rebuild went well.

 

Repeat the process for the next replacement.