Thread (39 messages) 39 messages, 7 authors, 2011-02-11

Re: libata: implement on-demand HPA unlocking

From: Alan Cox <hidden>
Date: 2011-02-09 21:10:24

On Wed, 09 Feb 2011 14:36:22 -0500
Phillip Susi [off-list ref] wrote:
On 2/9/2011 10:37 AM, Alan Cox wrote:
quoted
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.
It would be constructive to take a more general view of the situation
than trying to assign blame and complaints.
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.
Correct. The vendors however primarily used it for completely different
things. Also trusting the BIOS is generally not a good idea.
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.
Possibly because we unlock them in the distro cases.
quoted
"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 ).
I think you miss the point.

If you always unlock the drive then the software behaviour can be to
either honour or ignore the HPA. The HPA is a combination of two things

1.	An indication from the drive that there are two sets of
geometry patterns

2.	A crude hack from the proprietary "we know better" world.

So the best option from a kernel point of view appears to be to unlock
the drive but to remember and enable user space to retrieve the
parameters.

In essence "what geometry do I care about" is policy for application code
like dmraid, and it can be better refined there. However we can't refine
it there if we don't unlock.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help