Re: libata: implement on-demand HPA unlocking

[Tejun Heo <tj@kernel.org>]

On Wed, Feb 09, 2011 at 02:36:22PM -0500, Phillip Susi wrote:
> On 2/9/2011 10:37 AM, Alan Cox wrote:
> > Unlocking the HPA is actually necessary for sanity on a lot of systems
> 
> Right.. ones that were partitioned using an older kernel with the buggy
> behavior of unlocking it by default.

Claiming it a bug doesn't really make it a bug.  Please drop it.

> > too, and there are really no standards. Remember the primary use of HPA
> > has actually been to hide most of the disk from buggy BIOSen so that the
> > OS can then unlock it after the BIOS has stopped looking.
> 
> The ATA spec describes the HPA saying:
> 
> A reserved area for data storage outside the normal operating system
> file system is required for several
> specialized applications.

Heh, yeah, ATA spec says a lot of shit.

> This tells me that it is intended for the bios to reserve an area of the
> disk that the OS should NOT access.  So far the only use of it that I
> have seen is by bioses to hide a small area, presumably to store
> platform specific information.  I see about a dozen reports on the
> ubuntu forums and bug tracker each year of people with HPA problems and
> it always seems to be a small area, as opposed to hiding everything
> above 128 MB or something.

Yeah, nowadays.  It's not how it started tho.

> > "Should we unlock" is almost an academic debate given we are the OS and
> > control the commands sent to the drive anyway.
> 
> Again, Linus's tree does not unlock, and should not since the bios
> presumably had a reason for locking it in the first place ( it stores
> something there ).

libata didn't have HPA unlocking support at the beginning so it was
only natural to make the default to not unlock when the feature was
added.  For distros, the story is different because they migrated from
ide to libata.  ide unlocked by default so it was also natural for
them to make liata unlock it by default; otherwise, they could end up
with situation where upgrading to newer distro could break an
installation.

So, no, the situation has always been quite muddy with HPA and if you
ask me it is an inherently stupid feature bound to cause problems.
The setting is not even bound to the hard drive.  You move a hard
drive to a different machine, the size changes, hooray!  Oh right,
suspend/resume cycle can accidentally lock or unlock HPA areas on some
BIOSen and we have workaround for that in libata, yuck.

I think ide had it right all along.  We should just have unlocked
things by default when HPA unlock feature was added.  A lot of BIOSen
configure HPA for no reason anyway.  To continue the rant, I think
it's pretty silly to use fakeraid to begin with but maybe we should
just printk big ugly message to scare people away.  Ah well.

To sum up, no, not unlocking HPA by default was not a conscious
decision and neither was some distros defaulting to unlocking it.
Those decisions are all made by inertia, so please stop bringing them
up.  They don't mean much.

I think all we can do now is just let block layer publish before and
after sizes and adapt the tools accordingly.  I remember bringing the
idea quite a while ago with dmraid folks but IIRC nobody responded.  I
guess I'll make the change and hope others to take care of the rest.

I frankly don't care that much whether some silly fakeraids are broken
or not.  Maybe I should but they're so braindamanged and I just can't.

Thanks.

--
tejun