Had to mess with my unRaid as I had a disk red-ball.  Fixed that, and thought I'd update the parity from 1TB to 2TB while I was messing with it.  I thought I needed to go to 4.7 to do that (was running 4.4.2).

 

Without changing the parity drive (still 1TB, working 4.4.2 setup), I updated the memtest, bzimage and bzroot on my unRAID to 4.7.

 

After the reboot, it is saying that one of my drives is smaller than the original.  This makes no sense, as it is the same drive.

 

Basically a drive that worked on 4.4.2 i s red-balled on 4.7.  I've got two lines on my main webpage for disk 7:

Hitachi_HDS72101_JP2921HQ071MYA size 976,761,492

and a 2nd line in italic:

Hitachi_HDS72101_JP2921HQ071MYA size 976,761,496

 

So it seems to think there were 4 extra bytes before.

 

Any suggestions for what might be wrong and how to fix?

 

Thanks!

 

 

Do you have a Gigabyte motherboard?  (I suspect so)

 

If so, read a few threads about the "HPA problem" 

 

First thing I'd do is revert back to 4.4.2 so the system works okay.

 

Then read a bit to be sure you understand the HPA issue ... and then you can decide what to do next.

 

Meanwhile, boot to your system's BIOS, and see if your particular BIOS allows you to turn off the "Save copy of BIOS to disk" feature ==> as you'll see when you read the details, this is described differently on various Gigabyte boards, but it should be fairly easy to determine if you have the ability to disable it.  If you can disable this "feature", things get a lot easier.    If not, you have to be very AWARE of this issue as you move forward.

 

Read this thread for starters:  http://lime-technology.com/forum/index.php?topic=27543.msg242608#msg242608

 

... in particular, I outline what Gigabyte boards do in my long post at the end of the thread.

 

Thanks for the prompt reply and pointer, I will look into that issue.  However, I've got an MSI mobo, not a Gigabyte.  You don't know if MSI boards suffer from this as well, do you?

Thanks for the prompt reply and pointer, I will look into that issue.  However, I've got an MSI mobo, not a Gigabyte.  You don't know if MSI boards suffer from this as well, do you?

 

Hmm ... not aware of this with anything but Gigabyte boards.  Do you know if the disk was ever used with a Gigabyte board?

 

BTW, I mean to note this before:  r.e. "... So it seems to think there were 4 extra bytes before." => actually the difference is 4K bytes  (the numbers you're looking at are K bytes)

 

Another question:  You indicated you had an issue with a disk but have "fixed" it.  Is your system currently fine, with good parity?    i.e. did you run a Parity Check after you resolved the issue?

 

Are you back up and running okay with 4.4.2?    If so, what's the date of the last Parity Check?

 

Well, the link says that the syslog will let you know if you are dealing with HPA.  And mine syslog does mention HPA.  So apparently this affects really old MSI boards as well.  Will look into what I can do about it.  Not sure why it only applies to one of my 10 drives, though.

 

Just reverted to 4.4.2, looks like it is back to green-balls.

 

I had a drive fail, but I've replaced it now.  Says the last parity check was today.

Not sure why it only applies to one of my 10 drives, though.

 

If the HPA was added by your board, it probably behaves just like the Gigabyte boards do -- it only creates an HPA on ONE drive.  As long as that drive doesn't fail, it won't create it on any others.  Read my last post in the long thread for an idea on ways to workaround the issue.  [The best thing is to simply upgrade to a board that doesn't have the problem  ]

 

I do NOT, of course, know whether MSI works the same way ... but the fact you've only got one drive with the issue indicates that's likely the case.

 

One thing you definitely do NOT want to do at this point is disconnect the drive with the HPA ... that may result in another HPA being created !!

 

Question:  Do you have (a) a spare 1TB drive; and (b) an available SATA port on your system?

 

Unfortunately I don't have a spare 1TB drive nor an extra sata port.

 

In fact, I bought a pcie sata controller to add two sata ports so I could preclear the 2tb drive.  But adding the pcie card (to go along with a pci sata controller and a different pcie sata controller) caused the two drives on the pci controller to disappear.

 

That was another reason I wanted to see if 4.7 worked, that it might allow all three sata controllers to work.

 

BTW, my mobo hasn't had updated bios is 2007, which is what I'm on.  So it sounds like I need a new mobo.  crap.

Unfortunately I don't have a spare 1TB drive nor an extra sata port.

 

In fact, I bought a pcie sata controller to add two sata ports so I could preclear the 2tb drive.  But adding the pcie card (to go along with a pci sata controller and a different pcie sata controller) caused the two drives on the pci controller to disappear.

 

That was another reason I wanted to see if 4.7 worked, that it might allow all three sata controllers to work.

 

BTW, my mobo hasn't had updated bios is 2007, which is what I'm on.  So it sounds like I need a new mobo.  crap.

 

Well ... if you have an external drive (or another PC) with enough space on it, you could copy all of the data off of the "too small" drive;  then do a new config (still using 4.4.2 -- but do NOT physically remove the "too small" drive from the system -- otherwise the BIOS may write another HPA on a different drive);  and THEN (after it's re-computed parity for the new configuration) you could update to 4.7.

 

You could then upgrade to a 2TB parity drive.

 

Your PCIe vs. PCI controller cards are a different issue altogether.  Check your BIOS settings to ensure all of the slots are enabled.    In general these cards should be able to co-exist, but some chipsets don't "play well" together, so this may be one of those cases.

 

I finally had time to look into the HPA issue on the MSI board.  I went into BIOS, and it had a setting "System BIOS Cacheable" that was set to enable.  So I changed that the disabled, thinking that would fix the problem.

 

The array booted fine, so I tried updating from 4.4.2 to 4.7.  But 4.7 still shows the disk as too small.

 

Garycase, if you are still around, is there more I need to do once I've changed the mobo setting?  Searching limetech forum for HPA isn't yielding great results.  Since you are familiar with the problem, I was hoping you could point me at what to do next, assuming disabling "System Bios Cacheable" fixes the underlying issue.

 

Thanks!

I finally had time to look into the HPA issue on the MSI board.  I went into BIOS, and it had a setting "System BIOS Cacheable" that was set to enable.  So I changed that the disabled, thinking that would fix the problem.

System BIOS Cacheable has nothing to do with HPA. Assuming your current motherboard added the HPA (it may not have), changing the motherboard setting that wrote it after the HPA has been written will not erase it. You must run a drive utility to remove the HPA and set the drive back to full size, but that action of rewriting the size changes where things are on the drive, which for all intents and purposes erases it with regards to unraid.

 

When you remove the HPA from the drive, it will have to be rebuilt from the rest of your drives. MAKE SURE YOUR SYSTEM CAN COMPLETE A VALID PARITY CHECK WITH ZERO ERRORS BEFORE YOU PLAY WITH IT ANY MORE!!! Your data on that drive is at risk.

As I noted earlier, and Jonathanm just noted as well, you absolutely need to be sure you have good parity before doing anything else.  Since you indicated you had a good parity check just 4 days ago, you're fine.

 

I'd do what I suggested earlier ... copy all the data off the drive;  then simply do a "New Config" without including that drive in the config (still using 4.2 -- but do NOT physically remove the drive from the system -- then upgrade to 4.7; and then add the drive to the array and copy the data back.    This will put you "at risk" until parity is computed -- but only for a few hours.

 

In the process of pulling everything off the drive.  Next I will remove the drive and rebuild the parity from N-1 drives (this is the badly named "restore" button, right?).  Then I can move to 4.7.  At this point, when I add the drive back, it should be zeroed out as a new drive, thus removing the HPA section, correct?

 

Also, I have shares on, so some of the data on this drive includes partial data from folders split across several drives.  As long as I copy back to disk7 and not to the unRAID share, it will be able to put everything back together, correct?

 

Thanks for the help, I know I'm asking a lot of questions, but I'm trying to be careful and not lose any data.

Crap.  Trying to make sure I've fixed the BIOS so another HPA doesn't appear led me to this comment in the manual:

System BIOS Cacheable

Selecting [Enabled] allows caching of the system BIOS ROM at F0000h-FFFFFh,

resulting in better system performance. However, if any program writes to this memory

area, a system error may result. Setting options: [Enabled], [Disabled].

 

That's in the L2 cache I believe, not on harddisk.  Searching the msi forums finds almost nothing on HPA, and the only threads that include "Host Protected Area" are about whether hard drives support the feature.

 

I think I switched from one motherboard to another on my unRAID setup.  This would have been 2007 or so.  If the previous mobo was a gigabyte with HPA, so the drive already had HPA on it, would it look like what I'm seeing if I moved everything from a gigabyte board to an msi board?

 

I guess this goes along with my previous question.  The advice given above didn't mention running hdparm -N pXXXX, so I assumed turning off the "feature" in BIOS would allow unRAID to access the full drive correctly.  But if that were the case, wouldn't the same happen if I moved to a new motherboard that didn't have the feature? 

Next I will remove the drive and rebuild the parity from N-1 drives

 

NO !!  At least not physically.  Leave the drive connected, but "remove" it in UnRAID's drive assignment page.  IF your motherboard built the HPA (debatable based on your subsequent comment), then if it doesn't "see" a drive with an HPA, it will put one on another drive !!  You simply remove it from UnRAID -- not from the actual system.

 

 

Then I can move to 4.7.  At this point, when I add the drive back, it should be zeroed out as a new drive, thus removing the HPA section, correct?

 

Yes, you can move to v4.7, then add the drive back.  But this will NOT result in removal of the HPA ... it will simply be added with the smaller size.  It will work fine, just not be quite the size it could be.  IF you're sure the HPA was created from your previous motherboard (if that was a Gigabyte board that's a fairly good assumption), then you could remove the HPA before you add the drive back.    The easiest way to do that is to put the drive in a Windows machine and use HDAT2 to remove the HPA.  There are several threads that discuss how to do this, or you can simply read the tutorial on the HDAT web site [http://www.hdat2.com/ ]

 

 

Also, I have shares on, so some of the data on this drive includes partial data from folders split across several drives.  As long as I copy back to disk7 and not to the unRAID share, it will be able to put everything back together, correct?

 

You can simply copy the data to the same share and it will be correctly "put back together";  or if you want to be sure it's positioned in the same way it is now, just copy the entire folder back to the new disk7 and it will automatically be part of the share.    Either way works fine.

 

I think I switched from one motherboard to another on my unRAID setup.  This would have been 2007 or so.  If the previous mobo was a gigabyte with HPA, so the drive already had HPA on it, would it look like what I'm seeing if I moved everything from a gigabyte board to an msi board?

 

Yes, what you're seeing is exactly consistent with what you'd see if you were originally running on a Gigabyte board with the HPA issue, and then moved to a new non-Gigaboard.

 

If you're fairly certain that's what happened, then just do as I outlined above -- after you're ready to remove disk7 (have all the data copied off), just attach it to a Windows system; use HDAT2 to remove the HPA, and then add it back to your UnRAID system.

 

I misspoke, I meant remove the drive "... from the unRAID array", not physically remove it.  Sorry, should have said unassigned instead.  I'm currently rebuilding parity with disk 7 "empty", but still physically in the server.

 

I was thinking I would try hdparm -N -pXXXXX from a terminal window (with the drive not assigned) once the parity completes and reboot.  I was figuring if the HPA came from the older mobo, this would show no HPA in the syslog, or if the MSI mobo is doing it, I would see HPA in the syslog after reboot.  This seems safest, as it sounds like even if it is the MSI board doing it, it would reasonably add HPA back to the same disk, which would still be unassigned.

 

Is there a particular reason you recommend removing HPA from a windows machine instead of from a terminal window?  Or would my way work just as well?

 

Again, thanks for the patience and help!

I was figuring if the HPA came from the older mobo, this would show no HPA in the syslog, or if the MSI mobo is doing it, I would see HPA in the syslog after reboot.  This seems safest, as it sounds like even if it is the MSI board doing it, it would reasonably add HPA back to the same disk, which would still be unassigned.

 

It is NOT reasonable to assume that if your board is writing the HPA that it would write it back to the same disk.    It would likely write it to the first disk it detected.   

 

There IS a way to determine if you board does this.  Take a spare drive, and look at the exact number of sectors on it AND confirm it does not have an HPA.  Now physically disconnect ALL drives from your UnRAID system, and connect the spare drive to a motherboard SATA port.  Boot the system (doesn't matter if the spare drive is bootable ... you just need to turn on the system so the BIOS detects the drive and tries to boot.  Now shut down; connect the spare drive to whatever system you used to examine it with, and see if it still has the same number of sectors and no HPA.  If so, you're safe.  If your system adds an HPA to drives, it would have added one to this drive, since it was the only one on the system.

 

 

Is there a particular reason you recommend removing HPA from a windows machine instead of from a terminal window?  Or would my way work just as well?

 

Yes, I suggested it because I've used HDAT2 and KNOW it works well.  I'm not a "Linux guy", so am reluctant to suggest Linux tools when I'm not sure of the exact command sequences.  HDParm should, however, work fine ... and there are several threads here that discuss HPA removal, so you can certainly use that method instead.

 

Ok, thanks for all of the help.  I used hdparm from telnet  to remove the HPA.  Then unplugged all of the drives but disk7 (which was already unassigned).  Rebooted, with the unRAID usb out as well.  Shutdown, plugged all of the drives back in + unRAID usb, and rebooted.  Syslog showed no HPA!

 

So I've got the array parity checked, and have my disk7 without HPA!

 

I know it will take a while to add disk7 back in and move all of the contents back over, but I should have everything covered from here.

 

@garycase - thanks a ton for your help!

Excellent -- sounds like your HPA was indeed from your earlier board.

 

You can either add disk7 back now (with 4.2), or go ahead and do the upgrade; then add it back.    Won't matter, since there's no HPA to worry about