HPA on cache drive

[Kode]

I noticed this in my syslog last night:

 

Jun 1 18:22:31 Tower kernel: ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 0)

Jun 1 18:22:31 Tower kernel: ata6.00: HPA detected: current 586112591, native 586114704

Jun 1 18:22:31 Tower kernel: ata6.00: ATA-7: Maxtor 7V300F0, VA111630, max UDMA/133

Jun 1 18:22:31 Tower kernel: ata6.00: 586112591 sectors, multi 16: LBA48 NCQ (not used)

Jun 1 18:22:31 Tower kernel: ata6.00: configured for UDMA/100

Jun 1 18:22:31 Tower kernel: scsi 6:0:0:0: Direct-Access ATA Maxtor 7V300F0 VA11 PQ: 0 ANSI: 5

Jun 1 18:22:31 Tower kernel: sd 6:0:0:0: [sdg] 586112591 512-byte logical blocks: (300 GB/279 GiB)

Jun 1 18:22:31 Tower kernel: sd 6:0:0:0: [sdg] Write Protect is off

Jun 1 18:22:31 Tower kernel: sd 6:0:0:0: [sdg] Mode Sense: 00 3a 00 00

Jun 1 18:22:31 Tower kernel: sd 6:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

 

Which i think is saying that my cache drive has HPA on it (Its the only Maxter drive in the system, the rest are 1TB and 1.5TB Samsungs).  Is this going to cause me any issues?

 

Also, would running preclear remove HPA?  If not then that makes more sense.

 

My motherboard is an MSI K8N Diamond, however, the cache drive was originally in my htpc before i put an SSD in it, and the motherboard in that is a Gigabyte MA78GM-S2H.

[Joe L.]

I noticed this in my syslog last night:

 

Jun 1 18:22:31 Tower kernel: ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 0)

Jun 1 18:22:31 Tower kernel: ata6.00: HPA detected: current 586112591, native 586114704

Jun 1 18:22:31 Tower kernel: ata6.00: ATA-7: Maxtor 7V300F0, VA111630, max UDMA/133

Jun 1 18:22:31 Tower kernel: ata6.00: 586112591 sectors, multi 16: LBA48 NCQ (not used)

Jun 1 18:22:31 Tower kernel: ata6.00: configured for UDMA/100

Jun 1 18:22:31 Tower kernel: scsi 6:0:0:0: Direct-Access ATA Maxtor 7V300F0 VA11 PQ: 0 ANSI: 5

Jun 1 18:22:31 Tower kernel: sd 6:0:0:0: [sdg] 586112591 512-byte logical blocks: (300 GB/279 GiB)

Jun 1 18:22:31 Tower kernel: sd 6:0:0:0: [sdg] Write Protect is off

Jun 1 18:22:31 Tower kernel: sd 6:0:0:0: [sdg] Mode Sense: 00 3a 00 00

Jun 1 18:22:31 Tower kernel: sd 6:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

 

Which i think is saying that my cache drive has HPA on it (Its the only Maxter drive in the system, the rest are 1TB and 1.5TB Samsungs).  Is this going to cause me any issues?

 

Also, would running preclear remove HPA?  If not then that makes more sense.

 

My motherboard is an MSI K8N Diamond, however, the cache drive was originally in my htpc before i put an SSD in it, and the motherboard in that is a Gigabyte MA78GM-S2H.

It won't hurt anything, since your unRAID motherboard is not a Gigabyte.  If it was a Gigabyte, and the drive with the HPA failed, the BIOS would seek out a different drive to add one, and clobber your array.  think of it as a ticking time-bomb.

 

Running pre-clear will not remove the HPA, but running the hdparm command will.

See this post for an example:

http://lime-technology.com/forum/index.php?topic=5072.msg46903#msg46903

 

Joe L. 

[Kode]

Thanks Joe, thats put my mind at rest, if preclear doesnt get rid of it i'm pretty sure its from the htpc.

[Joe L.]

Thanks Joe, thats put my mind at rest, if preclear doesnt get rid of it i'm pretty sure its from the htpc.

pre-clear only can clear the space reported by the disk.  It has no idea of the space claimed by the HPA. 

 

There is a whole section in the wiki dealing with the HPA.  It is a major pain when it decides to make your disks smaller.  It is why many with gigabyte motherboard owners are replacing them in their unRAID servers.  That "feature" is a ticking time-bomb.

 

Let's pretend you have an HPA on disk1.  It makes it a tiny bit smaller than your parity disk of equal size.  Let's also say you have a second and third data disk without the HPA.  All is good... for now.

 

So four disks, one a tiny bit smaller because of the HPA added by the gigabyte bios.  It wants to add an HPA if it does not find one, and for now, it is happy, since there is one on disk1.

 

Now, some day, disk1 fails... or , the cable comes loose.  unRAID detects the failure and marks it disabled.

You reboot, in an attempt to fix it... the BIOS looks for a disk with the HPA and does not find one... so, it adds one to one of the other disks.

 

Now, either your parity drive ends up with it, and it is no longer the largest drive, so the array does not start, or one of the data disks ends up with it, clobbering the end of the file-system.  If you are very lucky, that area of the disk is unused, and it just makes the disk look smaller.  However... unRAID thinks it is a different disk since it is now a different size, so it marks it as the wrong disk for that slot.

 

Nice...  in either case your array will not start because you have two drives that are not valid. (The one with the loose cable, and the one that had its size changed)  The HPA becomes a major headache since you cannot just remove it at that point, you also have to fix the damage it has done to the unRAID array.

 

Trust me, this is not fun.  In one case, the Gigabyte bios made the HPA the entire data drive except for 32Meg of space.  In other words, a 1TB drive became a 32Meg drive.  unRAID then re-sized the partition table to fit. Again, a major pain.

 

 

 

 

[Rajahal]

Great explanation Joe.

 

Trust me, this is not fun.  In one case, the Gigabyte bios made the HPA the entire data drive except for 32Meg of space.  In other words, a 1TB drive became a 32Meg drive.  unRAID then re-sized the partition table to fit. Again, a major pain.

 

This sounds familiar.  Are you referring to when this happened to me?  I'm not totally sure that was caused by HPA, since adding a jumper to the drive fixed the problem (and I don't know of any other situations in which adding a jumper fixed an HPA problem).  I figured it was just a quirk with Samsung drives, and I have added a jumper to all Samsung drives before using them ever since (and they all have worked as expected).  However, I suppose it is possible that it was caused by HPA since I was using a Gigabyte board in my server in those days...

[Kode]

Quirk with Samsung drives? Jumper? This sounds like something i might need to know more about as 5 of the 6 disks currently in my array, and 2 disks waiting to go into the array when i get a SASLP card are Samsung (3 x 1.5TB and 4 x 1TB)

[Joe L.]

Great explanation Joe.

 

Trust me, this is not fun.  In one case, the Gigabyte bios made the HPA the entire data drive except for 32Meg of space.  In other words, a 1TB drive became a 32Meg drive.  unRAID then re-sized the partition table to fit. Again, a major pain.

 

This sounds familiar.  Are you referring to when this happened to me?  I'm not totally sure that was caused by HPA, since adding a jumper to the drive fixed the problem (and I don't know of any other situations in which adding a jumper fixed an HPA problem).  I figured it was just a quirk with Samsung drives, and I have added a jumper to all Samsung drives before using them ever since (and they all have worked as expected).  However, I suppose it is possible that it was caused by HPA since I was using a Gigabyte board in my server in those days...

No, not referring to your post, but instead to to this one.

 

Joe L.

[Rajahal]

Quirk with Samsung drives? Jumper? This sounds like something i might need to know more about as 5 of the 6 disks currently in my array, and 2 disks waiting to go into the array when i get a SASLP card are Samsung (3 x 1.5TB and 4 x 1TB)

 

I honestly don't know what to say about it since as far as I know no one else has encountered this quirk.  Perhaps it is isolated to my drives or my server.  However, once I have started installing jumpers on all Samsung drives before installing them in my server, I haven't encountered a single problem.