Finding unRAID on my search for a nas-system, I finally set up my first server with the goal to get to know it better.

 

After the first reboot the array did not start:

 

* Stopped. Replacment disk is too small.

 

Well, this is what we all like most for a first contact, don't we? Disk1 has now 1056 bytes less space, Disk status:

 

* Model - Size

* ata-SAMSUNG_HD753LJ_S13UAAAA40nnnn - 732,573,496

* ata-SAMSUNG_HD753LJ_S13UAAAA40nnnn - 732,574,552 (italics)

 

This seems to be not the first time this has happend, there are topics in this forum which report something similar:

- http://lime-technology.com/forum/index.php?topic=3385.0

- http://lime-technology.com/forum/index.php?topic=563.0

- http://lime-technology.com/forum/index.php?topic=1073.0

 

My questions:

1. In this situation, the best solution is to use "Restore" and assign the disks (with the smaller one) to the array again? (parity informatin is lost)

2. Can it be a problem in the future if the motherboard (the controler) changes? If the size of a disk changes again (getting 1056 bytes larger?) the parity-information might be broken. This makes me feel a bit unconfortable.

 

Some information which perhaps can help:

- 2 disks in the array: 1TB parity (SAMSUNG_HD103SI), 0,75TB disk1 (SAMSUNG_HD753LJ)

- both disks are new. The first time I powered them up was the first boot of unRAID. The array was created then.

- I installed unmenu, then did the first reboot of the system -> 1056 bytes missing.

- Motherboard is a Gigabyte GA-P35-DS4

- used the ICH9R SATA connectors (6 onboard), not the Gigabyte SATA2 chip (2 onboard)

- the system boots as USB-ZIP (I found no USB boot option in the bios)

 

Regards

 

Alex

 

Update:

While booting, some of these lines appear:

> attempt to access beyound end of device

> sdb: rw=0, want=1465148992, limit=1465147055

> Buffer I/O error on device sdb1, logical block 1465148928

Linux cannot remember the old size, can it? Hmm...

 

I just experienced a similar issue this morning.  Replaced a possibly failing 1.5TB parity drive and swapped with a new one.  After trying assigning it I couldn't run a parity rebuild because it was slightly smaller although they are both Seagate 1.5TB drives.  I had to take another new 1.5TB drive that I believe is attached to my Supermicro MV8 board instead of onboard and that seemed to work just fine.  Although I was hoping to keep the parity separated on it's own controller to increase speed.

I had the same issue you both are experiencing.  There is a Windows utility to remove the HPA (Host Protected Area) area from the disk and restore the full space back (Joe L. originally provided the link):

 

http://hddguru.com/content/en/software/2007.07.20-HDD-Capacity-Restore-Tool/

 

I successfully used this on three disks and was able to get my array functioning again.  You do need to have a windows machine that you can plug the disks into in order to run the utility.

 

Note, I ran the utility on blank disks, so I am not sure how it reacts if there is already data on the drive.  I would assume it works, but I am not 100% sure.

 

 

I had a similar problem with a WD-10EADS hard drive that I used in a Gigabyte MB.  The bios in the Gigabyte MB created an HPA area.  I used seatools to remove the HPA so I could use the full drive.  http://www.seagate.com/www/en-us/support/downloads/seatools

 

See the wiki here:  http://lime-technology.com/wiki/index.php/UnRAID_Topical_Index#HPA

Just read your post a little closer...  I see you have a Gigabyte MB and that is probably what is creating the HPA.  In my case, I moved a drive from a PC with a Gigabyte MB to my server with a Super Micro MB.  So removing the HPA worked fine for me, not sure if it would for you since you have a Gigabyte MB and it might just put it back on the drive again.

Yes I have a Gigabyte motherboard as well.  Seems like that must be my issue.

I tried to find out more about this "Gigabyte"-problem and have found some ideas what it is and perhaps what to do.

 

This are just guesses for know...

 

- Gigabyte uses "Virtual Dual BIOS", a copy of the BIOS is placed on the disk

- It is possible that only the disk on the prmary master is used (to be confirmed). So a solution could be to leave the first sata-port empty?

- Something I did not realy understand and perhaps is just wrong: The Gigabyte-Board puts 1,5 MB of data at the end of the disk. Overwriting everything there (hello parity...) And because only some bytes go in the HPA (host protected area), it might be that this oerwitten area is not protected and is just end the end of a formated partition. As I said, I might misunderstood this an this is not correct.

- there is a tool "mhdd" for low-level-editing disk-things. It seams to habe an option to disable the HPA-feature on the disk itself. I have no idea what the Gigabyte-BIOS would do with such a disk or what can happen afer a firmware-update of the disk.

 

Thinking about a solution for me, my current ideas are

- not using the Gigabyte GA-P35-DS4 (I wanted to use it until there is a nice atom-based mb which is supported, like the Supermicro X7SLA-H)

- putting a cache-drive on the first port (what I don not like: perhaps data is not written on the disk on the first port (=sata1), but on the first port where a drive is available. If the Cache-drive would die, the next disk might be changed)

- investigate an think a litle longer with your help...

 

Regards

 

Alex

information about the dual-bios from gigabyte:

http://www.gigabyte.com.tw/FileList/NewTech/2006_motherboard_newtech/article_04_bios_explained.htm

 

Isn't there a way to desable the dual bios ?

So it will not use the HD for backup.

I too have a Gigabyte board (P965-DS3 rev 3.3) and the tool I mentioned previously resolved the issue.  Another point of interest is that I had all 6 SATA ports used on the motherboard without HPA appearing.  Once I added a PCIe card that is when HPA was placed on the disks for that card only.  I believe once the disks are in and operational HPA will not be written to them, but that is just a theory.

 

I also had this issue on my Gigabyte GA-EP45-UD3P. The drive connected to the first sata port (SATA_0) was the one that was 1056 bytes smaller. I wanted to use that one for parity but couldn't, so I copied data to it instead and used my other 1.5tb drive for parity. It's been fine since then.

 

I couldn't find anyway to disable the bios backup features and haven't tried the tools mentioned here. Crossing my fingers the mobo doesn't decide to write a HPA block to one of the other drives.

Here an illustration what seems to happen when the gigabyte virtual bios is written:

 

disk1:

(.1.1.0.0.1.0.1.1.0.0.0.1.1.0.1.1.0.0.1.0.1.1.0.0.0.1.1.0.)

 

disk1 with hpa AND virtual BIOS:

(.1.1.0.0.1.0.1.1.0.0.0.1.1.0.1.1.0.0.1.0.i.o.i.o.i.o.)o.i.

 

() = usable space not protected by hpa

i,o = data written by the bios

 

That's a lot of fun in an array if the BIOS changes the data even with a hpa present:

 

disk1:

(.1.1.0.0.1.0.1.1.0.0.0.1.1.0.1.1.0.0.1.0.1.1.0.0.1.0).i.i.

disk2:

(.0.1.0.1.1.0.1.0.0.0.1.1.1.0.1.1.0.0.1.0.1.1.0.0.0.1.1.0.)

disk3:

(.0.1.0.1.1.0.1.1.0.0.1.1.1.0.0.1.0.0.1.0.1.1.0.0.0.1.1.0.)

parity:

(.1.1.0.0.1.0.1.1.0.0.0.1.1.0.1.1.0.0.1.0.1.1.0.0.1.0.0.0.)

 

Now the motherboard saves a new copy of the bios:

 

disk1:

(.1.1.0.0.1.0.1.0.0.0.0.1.1.0.0.1.0.0.1.0.i.i..o.i).i.i.

disk2:

(.0.1.0.1.1.0.1.0.0.0.1.1.1.0.1.1.0.0.1.0.1.1.0.0.0.1.1.0.)

disk3:

(.0.1.0.1.1.0.1.1.0.0.1.1.1.0.0.1.0.0.1.0.1.1.0.0.0.1.1.0.)

parity:

(.1.1.0.0.1.0.1.1.0.0.0.1.1.0.1.1.0.0.1.0.1.1.0.0.1.0.0.0.)

 

...and there goes the protection of array. The parity check should detect errors now.

 

 

Note that this will also happen if you put a disk out of the array on another (gigabyte virtual bios) motherboard as single drive to da a firmware update of the disk.

 

 

I decided not to use my Gigabyte GA-P35-DS4 for unraid. To unpredictable.

 

 

There is likely some intelligence in the Gigabyte MB to detect if the drive is new/unpartitioned.  Not sure how it figures that out.  But if it thinks it is a fresh disk, it feels it is safe to add the HPA.

 

The parity disk, however, is NOT partitioned.  It has no format and simply contains parity data from beginning to end.  Depending on the number of drives in the array and their contents, the parity disk may LOOK like it has a valid partition table to the BIOS (for example, with exactly one data disk, parity will be an exact mirror image of the single data disk).  But more likely the parity disk will look like random garbage to the BIOS.  I suspect that the MB is going to slap an HPA on the parity disk in many if not most cases.  As mole points out, this can and will mess up parity.  It may also cause unRAID to NOT start the array (if parity now appears smaller than the largest data disk).

 

Based on posts here, it seems that some ports (MB ports?) are subject to applying HPA and some are not (addon controllers?).  My advice would be to make sure that you put the parity disk on one that does not.  For the data disks that ARE going to be on ports that tend to apply HPAs, you might want to prepare the disks on other machines / ports.  I suspect that running the preclear script would likely be enough to avoid getting HPA applied, but that would have to be verified.

I had the same issue you both are experiencing.  There is a Windows utility to remove the HPA (Host Protected Area) area from the disk and restore the full space back (Joe L. originally provided the link):

 

http://hddguru.com/content/en/software/2007.07.20-HDD-Capacity-Restore-Tool/

 

I successfully used this on three disks and was able to get my array functioning again.  You do need to have a windows machine that you can plug the disks into in order to run the utility.

 

Note, I ran the utility on blank disks, so I am not sure how it reacts if there is already data on the drive.  I would assume it works, but I am not 100% sure.

 

I'm building my first unRAID and thinking of getting a GIGABYTE GA-MA785G-UD3H. No one has used this MB before, but I like that I can unLock the hidden core on AMD Sempron 140 CPU. Also the on-board video is nice. So how does the HPA happen? If you attach a new drive to the array there is a chance the MB will add the HPA. You then hook the drive up to windows to remove it and then back in the server to fix this problem? Is there a way to detect HPA was added to a drive?

The 785g motherboards appear to have a BIOS option that is disabled by default. From the manual;

 

Backup BIOS Image to HDD

Allows the system to copy the BIOS image file to the hard drive. If the system BIOS is corrupted, it will be recovered from this image file. (Default: Disabled)

 

It's in the advanced features.

 

If this is left off then there should be no HPA created. Try using <CTRL> F1 if your Gigabyte board does not show this option.

 

My board created a HPA when I played with one of the BIOS options that apears on boot. Somewhere in the Q-Flash utility or something like that.

 

Peter

My board created a HPA when I played with one of the BIOS options that apears on boot. Somewhere in the Q-Flash utility or something like that.

 

What MB do you have? Do you hit Ctrl-F while in the BIOS?

I have a GA-M78SM-S2H motherboard but I'm using in a HTPC. I have an ECS 740g based board in my unRAID box.

 

It does have a <CTRL> - F1 option that gives more options. I do not have that HPA option though.

 

However, there is a Q-Flash key I can press instead of the BIOS and it has the option to save the BIOS to the HDD. I just keep clear and the HPA is not created.

 

On another note, the motherboard is working amazingly well in the HTPC with a 4850e processor. I read about so many problems others are having with different boards and this one has not suffered any of them. It's not the fastest but it lots for a HTPC and some general computer use.

 

You could plan on putting the parity onto the SATA1 plug and just don't connect it at first until you have booted with the other drives connected.

 

Peter