EDIT see reply 3 below.   This has been edited to summarize the issue and efforts I have made.

 

I just noticed a flag in unMENU that suggests my two Samsung F4 drives are HPA?  I didnt think this was the case.  How do I determine what to do with them?

 

Screenshot from unMENU attached.

 

Additional info I think is relevant:

I do not have a Gigabyte MB in this computer.   It has a Biostar TA790GXE 128M.

The two Samsung drives are HD204UI and were both precleared with -A starting at 64.

I have a WD20EARS that was also precleared with -A, no jumper changes from the factory, and it is showing up as correct size.

 

I wanted to start copying data to the Samsung drives as soon as my parity build completes.  Any help is appreciated as I don't want to start till I hear if there is a problem.

 

Thanks

Yep - sure looks like you have an HPA (host protected area) on those disks. They can wretch havoc with unRaid. First thing is to figure out how they got there (normally a current or prior Gigabyte motherboard). If your current motherboard created them, you have to stop it from doing it again in the future. You then need to remove the HPAs.  This topic has been exhaustively covered in the forums, so do some searching. If you have questions, post back.

Yep - sure looks like you have an HPA (host protected area) on those disks. They can wretch havoc with unRaid. First thing is to figure out how they got there (normally a current or prior Gigabyte motherboard). If your current motherboard created them, you have to stop it from doing it again in the future. You then need to remove the HPAs.  This topic has been exhaustively covered in the forums, so do some searching. If you have questions, post back.

 

See the notes I just added above.  I have seen a lot written on it, but since I dont have a Gigabyte board I am confused.

 

EDIT:  Wait a minute.  When I first got these two drives, I knew it was going to be a while till I got this server built, so I did plug them into my other computer (which has a Gigabyte MB) and booted to a DOS based HD test utility.  I just wanted to make sure they would at least pass an 8 hour test before I got past the return policy at NewEgg.

 

So, if they could have been written with HPA that fast, how do I remove it and reformat? 

Also my other existing data drives are being plugged into this computer (with Gigabyte MB) to copy over to unRAID, then being moved into the unRAID server.  Will I have an issue with those as well?  If I turn this off in the BIOS, will it affect the drives already installed and staying there?

This has been edited to summarize where I stand

 

First this is what I found in my syslog file.

 

Jul 13 02:18:46 TODD-Svr kernel: ata2.00: HPA detected: current 3907027055, native 3907029168

Jul 13 02:18:46 TODD-Svr kernel: ata3.00: HPA detected: current 3907027055, native 3907029168

 

So with the array stopped, I used this command:

hdparm -N p3907029168 /dev/sdb

 

Here is what was returned:

/dev/sdb:

setting max visible sectors to 3907029168 (permanent)

max sectors = 3907029168/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?)

 

In addition when I run hdparm -N /dev/[hs]d[a-z], I get similar messages for all 4 HD's, including the two that do not show up as having HPA.  

However, sdb now shows the correct max sectors, and the hpa notification disappeared from the syslog, so I duplicated for sdc, same results.

 

Due to the odd returned message, I also checked with HDAT2, which all looked fine, no HPA.

 

Now what is happening is every time I start the array I get a single read error on both of these discs.

Additionally, when I ran a parity check I got exactly 265 errors on each drive at the end of the parity check.  unMENU noted these as errors requiring parity updates.  These could be due to the space now visible at the end of the drive that were not included in the parity calc the first time through.  However, look at the below paste from the syslog from the last array startup:

 

Jul 14 01:30:05 TODD-Svr kernel: attempt to access beyond end of device

Jul 14 01:30:05 TODD-Svr kernel: sdb1: rw=0, want=3907029104, limit=3907026991 (Drive related)

Jul 14 01:30:05 TODD-Svr kernel: md: disk2 read error (Errors)

Jul 14 01:30:05 TODD-Svr kernel: handle_stripe read error: 3907029096/2, count: 1 (Errors)

Jul 14 01:30:05 TODD-Svr kernel: attempt to access beyond end of device

Jul 14 01:30:05 TODD-Svr kernel: sdc1: rw=0, want=3907029104, limit=3907026991 (Drive related)

Jul 14 01:30:05 TODD-Svr kernel: md: disk3 read error (Errors)

Jul 14 01:30:05 TODD-Svr kernel: handle_stripe read error: 3907029096/3, count: 1 (Errors)

 

Are these drives actually slightly smaller and I now have the system looking for sectors that don't exist?

These were precleared as advanced format drives, starting with 64.  This is correct right?  Could this cause an issue if not?

 

Both drives passed preclear with no issues.  Both pass a SMART test with no issues.  Both drives have had successful firmware updates.

 

I will attach syslog with the parity update errors to a separate reply due to file size.  However, they are similar to the above.

 

Please, any help is appreciated.  I really don't want to continue to copy data until I know this is not an issue.

syslog-2011-07-14_-1.txt

sdb_SMART_Report_2011-07-14.txt

sdc_SMART_Report_2011-07-14.txt

You may need to hook the drives to a motherboard port to remove the HPA.

Syslog with parity update errors.

syslog-2011-07-14_-2.txt

 

I did call Samsung and they confirmed the last sector should be 3907029168 so everything should be set right.  Is the "limit" it is referring too, caused by the preclear and format while hpa was in place?

 

Can I re-format without pre-clearing?  I would need to maintain the start sector of 64, is there a command for this?  

I don't see an option of forcing a re-format.

Does the array currently store any data that you care about, or are your data disks blank?  Definitely back up any important data before proceeding as reformatting a disk will wipe its contents.  Also, the following is going to force you to lose parity protection for a while.  Essentially you will be starting your array over from scratch.

 

Yes, you can force a reformat.  Since you already have the preclear script installed, that is probably the easiest way to do it.  You'll want to use the -z flag:

 

Edit: Feb 4, 2011    1.4  - Added "-D" option to suppress use of "-d ata" on smartctl commands

                                    Added "-d device_type" to allow use of alternate device_types as arguments to smartctl.

                                  Added "-z" option to zero the MBR and do nothing else. (remainder of the drive will not be cleared)

 

The -z flag is included in all subsequent releases of the preclear script as well, you don't need to downgrade.  Preclear won't allow you to run itself on any disk assigned to the unRAID array (a nice little safety feature built in by Joe L.).  So your first step will have to be to break your array.  From the system console or telnet, type:

 

'initconfig' and confirm with 'Yes'.

 

Your parity data will be thrown away, and your array will be seen as brand new.  Any data on the data drives will still be there (though not for long).  The next step is to manually clear the MBR of each data drive.  This will erase the formatting of the drive.

 

The syntax would be:

cd /boot (or wherever you've stored the preclear script on the flash drive)

preclear_disk.sh -z /dev/sdX (where X is the drive letter)

 

After running this command (which should complete very quickly), the drive will show up as unformatted in unRAID (and all the data will be gone).  You can then use the unRAID 'format' button to reformat the drive (which should take 2-5 minutes).  I recommend doing this to one disk at a time.  As long as you have the 'mbr 4k aligned' setting enabled on the unRAID settings page, then the drives will be reformatted starting at sector 64.  Once you've finished the above for all disks, then you can start the array and let parity sync.  Once the parity sync is done, run a parity check.  Once the parity check completes without errors, then you are in the clear and you can start transferring data back into the parity protected array.

 

I believe that should solve your problem once and for all, at least as long as these disks never touch another Gigabyte board with HPA enabled.  This is one of several ways to address your issue, but in my mind it is the simplest and most logical.  There are ways to go about it without losing parity protection, but I don't think your parity data is trustworthy at the moment anyway, so why bother.  Still, if you don't want to have to start over from scratch, say the word and I or another can offer some different advice.  Via con dios.

Raj,

 

Thanks for your response.  

 

Because of these issues, I have not copied any data to either of these drives.  Only one drive (WDEARS) has any data, but it never had an HPA indicator in the syslog.  All of my data still exists in other locations.

 

So there is no reason to do anything with the WD drive right (it has about 1 TB copied over)?  I can just clear (with -z as noted above) the two Samsung drives and rebuild parity?

 

Also, what do you think about the odd hdparm response noted above? "HPA setting seems invalid (buggy kernel device driver"?

 

This occurred on all 4 drives, 2 of which never had HPA on them.  

 

If you would, please let me know on the above so I know how far to take this.  

Parity ran overnight and competed with no errors.

 

Thanks for the help!!

 

Back to copying data.

Correct, you shouldn't need to touch the WD drive, just the Samsungs.

 

I've seen the same HPA error message when messing about with short stroking drives (purposefully installing HPAs) in my prototype testing.  I'm not exactly sure what it means, but I don't believe it is anything to worry about.  As long as the new size sticks (and the HPA is gone), then you are in the clear.

 

I'm glad to hear your parity sync completed with no errors.  Did you run a parity check also?  It is important to do both.  The parity sync writes to the entire parity disk, while the parity check reads from it.  Until both complete without errors, you can't truly trust your array.  If you haven't already done it, start off a parity check now (it doesn't matter that you've already started transferring some data, the disks don't need to be empty).  You can actually run the parity check while transferring data, but it will make both processes take longer, so I suggest doing the check first and holding off on the data transfer.

Correct, you shouldn't need to touch the WD drive, just the Samsungs.

 

I've seen the same HPA error message when messing about with short stroking drives (purposefully installing HPAs) in my prototype testing.  I'm not exactly sure what it means, but I don't believe it is anything to worry about.  As long as the new size sticks (and the HPA is gone), then you are in the clear.

 

I'm glad to hear your parity sync completed with no errors.  Did you run a parity check also?  It is important to do both.  The parity sync writes to the entire parity disk, while the parity check reads from it.  Until both complete without errors, you can't truly trust your array.  If you haven't already done it, start off a parity check now (it doesn't matter that you've already started transferring some data, the disks don't need to be empty).  You can actually run the parity check while transferring data, but it will make both processes take longer, so I suggest doing the check first and holding off on the data transfer.

 

I'm dead in the middle of a copy.  Will run a check tonight as by then I will have enough copied over that I will want to erase some discs to move into the array and will want to "know" it is secure before doing so.

 

Thanks again.