I'm about 99% certain my current issue is related to HPA.

 

My situation is that I replaced my parity drive a month or two ago with WD Red 4TB drive.  I did not think about HPA possible issues at the time and as its my first 4TB drive, the byte size of the drive I had nothing to compare against. 

 

Today, I replaced my smallest data drive (1TB) with a precleared Hitachi 4TB .  My service is full (1 parity, 11 data), so swapping drives for bigger one's is my only option before making the plunge on a Norco server.

 

Where I sit now is that after turning the server back on, I am getting warning that the drive I am trying to install is larger than my parity drive. 

 

Would you suggest I re-install the 1TB drive I just pulled out and then restart the array.  Everything should be functioning normal again.  Then, deal with the parity drive being undersized.  I don't recall off hand, but with some searching I should be able to find how to remove the HPA and make the drive slightly bigger.

 

The new 4TB drive I am trying to swap in for the 1TB, I am going to have to do something with it also to make sure the HPA issues doesn't happen to it (although not as critical as if it ends up slightly smaller than the parity, no harm).

 

I am currently running UnRaid Server Pro ver 5.0.5

Parity Drive -  3907017476 Bytes

New Drive -    3907018532 Bytes

 

I'd appreciate the option of those more skilled / experienced with this than I. 

 

Thanks

Option 1: Create an HPA on the new HGST drive. This would destroy the preclear signature, but allow you to add it to the array.

 

Option 2: Do a new config and assign the new, slightly larger disk, as parity. You would want to put the 1T in the array but keep the old parity out. When parity was finished building, you could upside the 1T using the 4T containing the HPA.

 

I like #2.

 

Either way, you want to disable whatever is creating the HPAs. If the drive came from an external enclosure that could be the culprit. External drives sometimes contain HPAs. Or if you have a Gigabyte motherboard, there is an option to keep a backup of the BIOS that causes the HPAs. But knokw that once the HPA is there it is there, until you remove it. So fixing the HPA option on the motherboard would not do anything to solve this problem, but would protect you from having it happen again.

Option 3 ... which maintains a fault-tolerant option the whole time ...  (otherwise very similar to #2)

 

(a) Replace the 1TB in the array.  Do a parity check to ensure all is well (if you haven't just done this)

 

(b) Save a complete copy of the flash drive on your PC (so you can restore it if necessary)

 

©  Replace your parity drive with the new, slightly larger, drive, and wait for the rebuild to complete.  Do a parity check when that's done to confirm all is well.    [unlike with a new config, this doesn't lose fault-tolerance; since you could always replace the original parity drive and restore the exact flash drive contents if anything goes awary]

 

(d)  Now (as in Option 2 above) replace the 1TB drive with your old parity drive and let it do the rebuild.

 

 

Option 4:  Just do a parity-swap, where you replace the parity drive with your new, larger drive, and simultaneously replace the 1TB drive with your old parity.    When you Start the array, it will first copy the old parity drive to the new one, and clear any additional sectors on the new parity drive;  then it will rebuild the old (1TB) drive onto the old parity drive.    This maintains fault tolerance throughout the process, but doesn't verify the parity copy, so it's a tad riskier than #3.

 

Option 3 ... which maintains a fault-tolerant option the whole time ...  (otherwise very similar to #2)

 

(a) Replace the 1TB in the array.  Do a parity check to ensure all is well (if you haven't just done this)

 

(b) Save a complete copy of the flash drive on your PC (so you can restore it if necessary)

 

©  Replace your parity drive with the new, slightly larger, drive, and wait for the rebuild to complete.  Do a parity check when that's done to confirm all is well.    [unlike with a new config, this doesn't lose fault-tolerance; since you could always replace the original parity drive and restore the exact flash drive contents if anything goes awary]

 

(d)  Now (as in Option 2 above) replace the 1TB drive with your old parity drive and let it do the rebuild.

 

 

Option 4:  Just do a parity-swap, where you replace the parity drive with your new, larger drive, and simultaneously replace the 1TB drive with your old parity.    When you Start the array, it will first copy the old parity drive to the new one, and clear any additional sectors on the new parity drive;  then it will rebuild the old (1TB) drive onto the old parity drive.    This maintains fault tolerance throughout the process, but doesn't verify the parity copy, so it's a tad riskier than #3.

 

Option #3 - is kinda silly. Option 2 provides recoverability and does it all in one step. Taking a backup of the config folder is a good idea.

 

Option #4 - Parity swap and new config are functionally the same. This is another way of doing option 2.

Option #3 - is kinda silly. Option 2 provides recoverability and does it all in one step. Taking a backup of the config folder is a good idea.

 

Thinking about it, it's true that option 2 can provide recoverability as well, as long as you create a complete backup of the flash drive before starting (which would let you replace the original parity drive in the event of a problem).    But Option #3 preserves your current configuration -- plug-ins, Dockers, etc. -- whereas #2 creates a new configuration, so all of those would have to be redone.  The TIME involved should be identical ... both have to write the new parity drive; and both do a rebuild of the old 1TB drive on the old parity drive.  I did suggest a couple extra parity checks to confirm everything went well ... but those can certainly be skipped if you want to take a bit of extra risk (I'm just a VERY risk-averse kind of guy).

 

 

Option #4 - Parity swap and new config are functionally the same. This is another way of doing option 2.

 

Not true.  As with Option #3, there's NO change in the configuration with a parity swap -- add-ins, plug-ins, Dockers, etc. are all preserved.  Parity swap is more akin to #3, where you're not changing the configuration.  The primary difference is there's no validation of the new parity disk after it's written ... it simply then proceeds to do the rebuild of the old (1TB) disk onto the old parity drive.    This would, of course, be the FASTEST option.

 

Actually, as I posted that, I realize that #4 is NOT the "fastest" option.

 

The fastest option is not one I'd recommend ... but Option #1 listed by Brian is the fastest.  A couple minutes to resize the new drive (various ways to do that in just a couple minutes) ... and then you could simply do the rebuild of the old 1TB drive with it, since it would no longer be larger than your parity drive.

 

I wouldn't suggest it, however, unless you plan to replace your parity drive with a larger drive (e.g. 5TB or 6TB) in the near future -- BEFORE you need to change any other drives.    Otherwise, you're just delaying a solution to the same issue ... next time you want to install a 4TB drive you'll be right back where you started here.

 

My current parity drive is as WD Red, so I was thinking that would be the best drive for the job (being the drive designed for a NAS and the drive that gets the most activity).

 

Yes, I have a darn MSI motherboard.  It has been a few years, but I remember going through some process to redo a bunch of my 1.5TB drives that were slightly undersized.  At that time, the issue never happened to my parity (just by chance).

 

Short of replacing my motherboard, is their a permanent solution to prevent this from happening again?

 

I am new to the 4TB drive world and I just figured using a drive made for a "NAS" as my parity would be better than the Hitachi drive.  The WD Red has been in a few months and proven reliable.  That being said, the Hitachi did pass "preclear", so its trustworthy thus far (ie. not D.O.A.).

 

I don't mind taking a little risk as my data drives are just rips of my DVD's and CD's , so nothing that is life or death if its lost, just time.  That being said, its a lot of time, so I prefer not to get in it.

 

Would you guys personally run the WD Red or the Hitachi as your parity?

 

I do hate how long it take to run parity checks on these bigger drives.

 

Do these steps seem practical, taking a bit of risk but risk I feel is reasonable (ie. knowing the data drives are good after step 2):

 

1.  Put the 1TB data drive back in the server

2.  Run a parity check to ensure everything is hooked up ok and no cable knocked around with all my fiddling

3.  (Taking a bit of risk) - take the parity drive virtually out of the array (ie. just in the Unraid setup)

4.  Perform whatever is needed to get the parity drive to the proper size without HPA

5.  Add Parity drive to the array and let it rebuild / run parity check

6.  Replace 1TB with precleared Hitachi 4TB

 

 

 

... Short of replacing my motherboard, is their a permanent solution to prevent this from happening again?

 

Look in the BIOS and see if you can turn off the automated BIOS backup function that is what results in the HPA's.  If not, the answer is no, although you could avoid it by ensuring your parity drive is always attached to an add-in controller -- NOT to a motherboard SATA port.

 

 

I don't mind taking a little risk as my data drives are just rips of my DVD's and CD's , so nothing that is life or death if its lost, just time.  That being said, its a lot of time, so I prefer not to get in it.

 

You apparently don't feel your data is worth backing up (a common feeling).  Just be sure you understand the risk that entails (I think you do).  Personally, I don't EVER want to have to rerip my thousands of DVDs and CDs, so I have a complete set of backups (actually I have 2 sets of backups, since I decided last year to supplement my offline disks with a backup server).

 

 

Would you guys personally run the WD Red or the Hitachi as your parity?

 

Doesn't matter.  Personally, I only use NAS-rated drives for ALL of my drives; but the Hitachi drives are very good drives and should work fine in either capacity.

 

 

Do these steps seem practical, taking a bit of risk but risk I feel is reasonable (ie. knowing the data drives are good after step 2):

 

1.  Put the 1TB data drive back in the server

2.  Run a parity check to ensure everything is hooked up ok and no cable knocked around with all my fiddling

3.  (Taking a bit of risk) - take the parity drive virtually out of the array (ie. just in the Unraid setup)

4.  Perform whatever is needed to get the parity drive to the proper size without HPA

5.  Add Parity drive to the array and let it rebuild / run parity check

6.  Replace 1TB with precleared Hitachi 4TB

 

I'd do #1 and #2.  But then I'd just replace the parity with the HBA-free Hitachi and not bother with #4.  Once parity was rebuilt, I'd do #6 (replacing the 1TB with the WD Red).  Note this is simply what I outlined earlier as Option 3.

 

But if you DO want to remove the HPA, you can simply boot to an HDAT2 CD (free) and use the SetMax function to reset the drive to its native size.  Be CERTAIN you apply this to the correct dirve -- the safest way to do it is to not have any other drives connected to the system where you do it.

 

 

Forgot the link:  http://www.hdat2.com/