I'm replacing a 4TB HGST parity drive that failed with a 4TB WD Green drive   And unraid won't let me because it turns out it's slightly smaller.  Is there any way I can fix this without going out to get another drive?  Thanks!!

Is this a new drive?

 

If not, it seems like it's got an HPA (host protected area), which uses a few bytes of the drive and makes the effective space slightly smaller.    You can reset it to the maximum size with the "SetMax" function on the free HDAT2.

 

Just download the free ISO; create a bootable CD; and boot to HDAT2 ... then reset the drive's size.  The safest way to do that is to be sure the drive you want to examine/change is the only drive in the system when you boot to HDAT2 ... that eliminates any possibility of changing the parameters on the wrong drive [Just use a spare system ... or temporarily just unplug all the SATA cables from the other drives]

 

I've seen that before; just run the pre-clear proces on it first, after that the size will match.

The gui shows the size of a non-cleared or non-formatted disk not entirely correctly or at least it is confusing:

 

Could it be the unraid webgui is showing the wrong size?

The gui shows 3,907,018,532 bytes for a 4TB Hitachi, while the SMART report shows 4,000,787,030,016.

 

Preclear also shows 4,000,787,030,016 for the WD red... which would mean it would fit... it's exactly the same size as the Hitachi it replaces...

Maybe this helps. check if smart shows the correct size.

Argh I'm so sorry! Should've mentioned I ran a preclear on it already.  And it said it was successfully precleared.  Maybe it wasn't done properly?

 

The preclear was run on a difference computer though.  Then plugged it in, and got this.  Is there a way to check if the drive is precleared?  If that's all that would take, i'd be soo happy!  I don't mind running another preclear.  Downloaded HDAT2, will run that as well when I get home from work.

 

I've been having so much trouble with this drive! It's less than a year old and it failed.  Then I ordered a replacement and it was broken off the go and couldn't even be precleared.  And now this.  I thought there must be some higher power that does not want me to do this!

 

Thanks for all the help!

... The preclear was run on a difference computer though.

 

I suspect that other computer had a Gigabyte motherboard that does an automatic "BIOS Backup" to the hard drive.  It does this by creating an HPA to store the backup ... which slightly reduces the size of the hard drive.  There are a few other (non-Gigabyte) boards that do this as well, but Gigabyte boards are the worst offenders.

 

HDAT2's SetMax function will resolve this very easily.

 

Thanks! I had no idea these issues existed.  After hours of puttering around, finally I found this amazing post : http://lime-technology.com/forum/index.php?topic=16541.0

You should have asked ... I would have posted the same set of instructions.  I forget sometimes that it's not always intuitive for folks to use HDAT2.

 

Haha sorry! You're too nice.  But this is probably good practice for problem solving.  I have so little experience with hardware side of this stuff that figuring something out while being taught feels pretty damn nice!  Hopefully I'll have this fixed tonight.

 

Do I need to run preclear again after running HDAT2?  And if I run the preclear again on the same computer as before, will the same problem happen again if I don't turn off HPA?  I hope there is a way for me to turn off the HPA stuff in the bios.

No need to re-run the pre-clear.    If you were ADDING the drive to your array, then a pre-clear would make it a quicker process; but since you're replacing a drive (parity in this case), it won't matter.

 

As for the system you pre-cleared it on adding the HPA ... Yes, it may very well just do it again if you attached that drive to the system.    Look in the BIOS and see if there's an option to disable the automatic BIOS backup function ... this is what (at least on Gigabyte boards) results in the HPA.

 

Perfect!! Thankyou!!

So I went through the instructions and loaded HDAT2.  But then it says "set_max" not supported.  I also tried the hdpram option but that failed as well.  I attached the output of the two.  Sorry for the pictures of screens and all the stupid questions!

 

Interesting ... I've never seen HDAT refuse to reset the size.

Not sure why it's doing so here.

 

Try doing it with the Linux HDPARM command, as outlined by JoeL here:

http://lime-technology.com/forum/index.php?topic=3739.msg49310#msg49310

 

Okay so I had be away and tried this again Hopefully something comes of this.  I tried HDPRAM and it failed too

 

http://i.imgur.com/4zhIYMW.jpg

 

Is there something else I can try? Or do I have to get a 5tb drive?

If its for your parity drive, get a 6TB and future proof your disk upgrades going forward. After that just add the 4TB as a new data drive.

I use Seatools for DOS (it will work on all brands of drives) to remove the HPA. Seatools has never let me down. The HDPARM method never worked for me.

 

http://www.seagate.com/ww/v/index.jsp?locale=en-US&name=SeaTools&vgnextoid=720bd20cacdec010VgnVCM100000dd04090aRCRD

 

Advanced > Set Capacity

Three choices are available under this section, I use "Set Capacity to MAX Native"

Certainly won't hurt to try Seatools ... although it's interesting this disk has refused to allow the SetMax writes from both HDParm and HDAT2.

 

 

 

 

Thanks! I'll try seatools next!

I think I'm out of luck.  Seatools didn't work.  If I choose "set to max", it gives me a dialog box, same as the "set manually" and then nothing happens.  I think the WD green drive is smaller than the HGST drive.  I may have to look for a 5 or 6tb drive and just bite the cost.  But how -N failed is very odd.

I'm using the same make/model drive as my parity and I can confirm that it should be the exact same size as every other 4TB drive:

parity WDC_WD40EZRX-00SPEB0_WD-WCC4EF2YL0NZ (sdb) 3907018532 * 4 TB

 

One reason I wouldn't suggest just moving to a 5/6TB drive is that you may (down the line) run into the same thing once you start adding 5/6TB data drives, unless you fix the underlying cause.

Sounds like an  HPA. Are you running a Gigabyte motherboad, or has this drive every been installed in a computer with a Gigabyte motherboard?

Sounds like an  HPA. Are you running a Gigabyte motherboad, or has this drive every been installed in a computer with a Gigabyte motherboard?

 

Suggested LONG ago (the very first response) ... this whole thread has been about trying to get the drive to accept a "Set Max" command via one of the many tools that provide for that.

 

It's clearly NOT an HPA issue.

[More precisely, an HPA is not the issue at this point -- it may very well be that there is an HPA on the disk;  but the problem is that none of the normal tools for removing it are working => so at this point an HPA is not the problem]

 

 

 

I'm using the same make/model drive as my parity and I can confirm that it should be the exact same size as every other 4TB drive:

parity WDC_WD40EZRX-00SPEB0_WD-WCC4EF2YL0NZ (sdb) 3907018532 * 4 TB

 

Agree -- the manufacturers are VERY consistent with the drive sizes.  And as you can see in the quoted post, the size for the WD40EZRX is exactly the same as your HGST.

 

I don't know why your drive isn't accepting the SetMax command.  You either have a defective drive, or an issue with your controller. 

 

Do you have another system you can put this drive in and try using HDAT2's SetMax again?    This would at least confirm whether your controller or your drive is the issue.

 

Also, if you boot to the BIOS, are your drives correctly shown as 3 & 4 TB drives?

 

 

Has the "hdparm" method been tried?

Has the "hdparm" method been tried?

 

READ the thread 

 

... the entire thread has been about trying to reset the drive's size.  As for your specific question:

 

... I tried HDPRAM and it failed too

The hdparm command used was wrong.You should run the command hdparm -N /dev/sdb (assuming the disk is on sdb).

 

Here is the result of running the command on a 4T drive in my system:

root@Tower:~# hdparm -N /dev/sdm

/dev/sdm:

max sectors  = 7814037168/7814037168, HPA is disabled[

 

When you run the command to change the HPA, you give it the number of SECTORS not the number of BYTES or KBYTES. Running this command tells you exactly how many sectors are on the drive and how many are active. And will tell you if an HPA is enabled.

 

There are certain rules about the drive having to have been powered down since the last attempt to muck with the HPA to accept the change, and that multiple attempts to affect the HPA without a power down of the drive (not just a reboot) would not be successful.

 

I have also had issues with hdparm on certain controllers. All controllers respect the HPA in place, but only certain ones have the capability to report, set and remove them. In my experience, motherboard ports always work. But my experience is slight given the universe of motherboards out there.

 

Run the hpparm command above (hdparm -N /dev/sdb) and post the output. I expect it will tell you there is a small HPA.

 

If so, POWER DOWN the server (leave off for 30 seconds or more).

 

Then power back up and run the command:

hdparm -N -p7814037168 /dev/sdb

 

Then run the command:

hdparm -N /dev/sdb

 

It should report the disk is now full size.

 

Assuming it works, power down the server again afterwards, power on and boot, and you should be in business.

 

Good luck!