Hey all,

 

While adding a new drive to my array I discovered that some of existing drives were HPA enabled. (by receiving an error 'parity is not the biggest..')

 

I've searched and read a lot of posts (starting string here: http://lime-technology.com/wiki/index.php/UnRAID_Topical_Index#HPA) causing me to do the following:

1) I wasn't able to figure out how to disable HPA on my Gigabyte mobo, so I made the cache drive boot first (first SATA) and now its HPA enabled.

2) I disabled HPA on the 2 drives I had installed (disk1 and parity) using hdparm -N p..... (which was probably a mistake doing for both)

3) I used unraid_partition_disk.sh for the parity drive, found here: http://lime-technology.com/forum/index.php?topic=5072.msg47122#msg47122

4) I tried reiserfsck --rebuild-tree on the parity drive, but I get: Aborted (core dumped)

 

syslog and screenshot are attached. (btw, disk5 is disconnected - which is fine)

 

Question is - what's next? totally lost here..

syslog-20131004-164729.zip

Question is - what's next? totally lost here..

Set a new configuration, format the drives and restore your files from backup. Also, if you can't find a way to disable HPA, you will need to replace the motherboard. If your cache drive is not present on any boot for any reason, your motherboard will happily corrupt the next disk it finds. Most boards that lack the ability to disable HPA have an updated BIOS that includes the ability to turn it off, hopefully it defaults to off when the CMOS battery dies, otherwise you once again have a ticking time bomb.

 

BTW, recovering data is probably possible, it's just going to be a real pain, much easier to just restore from backup.

You're saying there's no way of getting this array back online? with the HPA that's still enabled (BIOS) left a side (still trying to figure out how to turn it off)

How would one restore the data if one is the parity drive and other is the data drive?

Is reverting the hdparm change back an option?

You can try using reiserfsck to recover the file system on each disk. hdparm modifies the disk partition making the disk unrecognizable by unRAID. The correct procedure is to do the disk one at a time rebuilding each disk in turn.

 

You did not "disable" HPA on the disks. The HPA was removed from the disks and will eventually be recreated on the disk by the MB. The MB has HPA enabled and will keep infecting the disks. The MB will not work in an unRAID server. Unless a BIOS update that makes HPA off by default is available, the board will never work.

Thanks for the insights.

I am considering a new mobo, which means a whole new computer (mobo+cpu+mem) - however I'm still exploring the options..

 

What if I use a SATA Controller - will HPA be created on these drives as well (assuming no drives are connected through the mobo)?

At this stage, it's probably too late to recover these disks ... I'd be sure they no longer have HPA's, pre-clear them, and simply build a new array.  As long as there's a detected disk that has an HPA, the motherboard should not add one to any other disk ... so that will work as a "workaround" (as you know) => but runs the risk that if that disk every fails you'll encounter the issue again.

 

Simply do a completely new rebuild of your system, and then copy your data back onto it from your backups.    Note that any data drives that do not have HPA's can be used as is -- their data will still be intact when you do a new configuration, as long as your add them before you add the parity disk.  (you can add them at the same time -- just not after you've done a parity sync)

 

BTW, if you ever encounter this problem in the future (not likely I suppose), the easiest (and safest) way to remove an HPA is to use the "Set Max Address" function in HDAT2  [http://www.hdat2.com/ ]

 

What if I use a SATA Controller - will HPA be created on these drives as well (assuming no drives are connected through the mobo)?

 

That would work.