libata: implement on-demand HPA unlocking

libata: implement on-demand HPA unlocking

[Phillip Susi]

Commit d8d9129ea28e2177749627c82962feb26e8d11e9 appears to be an attempt
to fix long standing problems with the Host Protected Area defaulting to
locked/unlocked and the problems that each guess has when it is wrong.

It still causes problems with fakeraid striped arrays however, because
it detects the partition table on the primary disk, sees partitions
beyond the end, and chooses to unlock the HPA to attempt to access those
partitions.  This breaks the fakeraid array since the raid metadata left
by the bios uses the HPA geometry, which becomes incorrect when the HPA
is unlocked.

I propose a slight refinement of the method introduced in this patch.
Rather than unlock the HPA if a partition goes beyond the end of the
current disk, it should check to make sure that doing so will actually
make that partition fully accessible, and don't bother unlocking if it
won't.

Thoughts?

Re: libata: implement on-demand HPA unlocking

[Tejun Heo]

Hello,

On Tue, Feb 08, 2011 at 03:23:36PM -0500, Phillip Susi wrote:
> It still causes problems with fakeraid striped arrays however, because
> it detects the partition table on the primary disk, sees partitions
> beyond the end, and chooses to unlock the HPA to attempt to access those
> partitions.  This breaks the fakeraid array since the raid metadata left
> by the bios uses the HPA geometry, which becomes incorrect when the HPA
> is unlocked.

Fakeraids, awesome as always.  So, they fail if the member disks are
unlocked?  Aiee...

> I propose a slight refinement of the method introduced in this patch.
> Rather than unlock the HPA if a partition goes beyond the end of the
> current disk, it should check to make sure that doing so will actually
> make that partition fully accessible, and don't bother unlocking if it
> won't.

The decision to unlock native capacity is made at the block layer
where the native capacity is unknown and then when the driver method
is called it doesn't know how long the partition table wants.  Of
course, we can change things such that the length partition table
wants is propagated downwards but I don't know.  How big a problem is
it?  Does the problem happen with a lot of fakeraids?  Maybe a better
way is to export BIOS size and let fakeraid use it?

Thanks.

-- 
tejun

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/9/2011 3:59 AM, Tejun Heo wrote:
> Fakeraids, awesome as always.  So, they fail if the member disks are
> unlocked?  Aiee...

Since the metadata is stored relative to the end of the disk, yes,
unlocking it causes its position to change.  The same problem should
apply to mdadm, though the odds are much higher that when mdadm created
the array, it was also running on a kernel that unlocked the HPA.

> The decision to unlock native capacity is made at the block layer
> where the native capacity is unknown and then when the driver method
> is called it doesn't know how long the partition table wants.  Of
> course, we can change things such that the length partition table
> wants is propagated downwards but I don't know.  How big a problem is
> it?  Does the problem happen with a lot of fakeraids?  Maybe a better
> way is to export BIOS size and let fakeraid use it?

It is a big problem for anyone using fakeraid ( which is quite popular
these days ) and has a bios that enables the HPA.  I think this is a
better solution because aside from the problems it causes to fakeraid,
unlocking the HPA defies the relevant standards and will trash whatever
data the bios is storing there, which is not good either.  Hence why I
am in favor of the idea of only unlocking the HPA if it is clear that
the disk was partitioned with a previously broken kernel and so it must
be unlocked to access existing user data.  That is why I like this
commit, but it misses the mark in raid situations where the MBR is
visible on the raw disk, but really is supposed to apply to the whole raid.

Re: libata: implement on-demand HPA unlocking

[Tejun Heo]

On Wed, Feb 09, 2011 at 03:37:14PM +0000, Alan Cox wrote:
> Probably the fakeraid layers need a way to see the geometry reported
> before unlock, then they can make their own decisions. The lock/unlock in
> hardware is just a hardware hack. We can still do the unlocking of
> hardware and using whatever values we choose in software at different
> points.
> 
> "Should we unlock" is almost an academic debate given we are the OS and
> control the commands sent to the drive anyway.

Agreed.  We're screwed whether we unlock or leave it alone.  I think
the best way is to export the original size via sysfs and always
unlock and let dmraid and whatever stuff which expects metadata at the
end use the bios size.  I seem to recall actually implementing it.
Wondering where it went....

-- 
tejun

Re: libata: implement on-demand HPA unlocking

[Alan Cox]

> better solution because aside from the problems it causes to fakeraid,
> unlocking the HPA defies the relevant standards and will trash whatever

Unlocking the HPA is actually necessary for sanity on a lot of systems
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.

> data the bios is storing there, which is not good either.  Hence why I
> am in favor of the idea of only unlocking the HPA if it is clear that
> the disk was partitioned with a previously broken kernel and so it must

We cannot create a situation where any system that now unlocks the HPA
ceases to do so, that breaks back compat in a potentially catastrophic
way.

> be unlocked to access existing user data.  That is why I like this
> commit, but it misses the mark in raid situations where the MBR is
> visible on the raw disk, but really is supposed to apply to the whole raid.

Probably the fakeraid layers need a way to see the geometry reported
before unlock, then they can make their own decisions. The lock/unlock in
hardware is just a hardware hack. We can still do the unlocking of
hardware and using whatever values we choose in software at different
points.

"Should we unlock" is almost an academic debate given we are the OS and
control the commands sent to the drive anyway.

Alan

Re: libata: implement on-demand HPA unlocking

[Jeff Garzik]

On 02/09/2011 10:36 AM, Tejun Heo wrote:
> Agreed.  We're screwed whether we unlock or leave it alone.  I think
> the best way is to export the original size via sysfs and always
> unlock and let dmraid and whatever stuff which expects metadata at the
> end use the bios size.

Agreed...

	Jeff

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

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.

> 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.

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.

> We cannot create a situation where any system that now unlocks the HPA
> ceases to do so, that breaks back compat in a potentially catastrophic
> way.

We already have that situation today.  This is the reason why Ubuntu
defaulted to having libata unlock the HPA by default, even though
Linus's tree did not ( and AFAIK, still does not, excepting the commit
in question here ).  No matter which choice you make, you cause some
breakage, so the goal is to minimize that breakage.  This commit
attempts to do that by auto unlocking the HPA iff it appears necessary
to access user data.  It is that test that I am asking be refined a bit
since it finds false positives for raid users.

> Probably the fakeraid layers need a way to see the geometry reported
> before unlock, then they can make their own decisions. The lock/unlock in
> hardware is just a hardware hack. We can still do the unlocking of
> hardware and using whatever values we choose in software at different
> points.
> 
> "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 ).

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/9/2011 10:36 AM, Tejun Heo wrote:
> Agreed.  We're screwed whether we unlock or leave it alone.  I think
> the best way is to export the original size via sysfs and always
> unlock and let dmraid and whatever stuff which expects metadata at the
> end use the bios size.  I seem to recall actually implementing it.
> Wondering where it went....

I am now confused since you are the author of
d8d9129ea28e2177749627c82962feb26e8d11e9, which seems to be entirely
aimed at NOT always unlocking by default, as Ubuntu has been doing, and
instead only unlock if it seems needed to access user data.  I like the
idea, but it gets false positives for dmraid users, so it should be
refined a bit.

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/9/2011 1:48 PM, Jeff Garzik wrote:
> On 02/09/2011 10:36 AM, Tejun Heo wrote:
>> Agreed.  We're screwed whether we unlock or leave it alone.  I think
>> the best way is to export the original size via sysfs and always
>> unlock and let dmraid and whatever stuff which expects metadata at the
>> end use the bios size.
> 
> Agreed...

Then why did you have libata default to NOT unlocking it, which seems to
be the correct thing to do?  When Ubuntu switched to libata they patched
it to default to unlocking the HPA because the old ide driver did.  This
seems wrong and causes breakage.  Tejun's patch seems to be a good
compromise between the two choices: unlock if you think it will help,
otherwise, don't, since it might hurt.

Re: libata: implement on-demand HPA unlocking

[Greg Freemyer]

On Wed, Feb 9, 2011 at 2:36 PM, Phillip Susi <psusi@cfl.rr.com> 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.
>
>> 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.
>
> 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.
>

Philip,

At some point (maybe 10 years ago), Dell used a HPA hidden partition
to hold a diagnostic partition of some sort.  I never used it, but I
remember coming across it several times.  I don't recall how big it
was.

I assume their thought was to have a recovery / diagnostic area that
normal users couldn't get to.  Now they just use a normal partition
for that.

I gather fakeraids now use a HPA protected to hold metadata for how
the raid is built, but I may have that wrong.

Greg

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/9/2011 3:47 PM, Greg Freemyer wrote:
> I gather fakeraids now use a HPA protected to hold metadata for how
> the raid is built, but I may have that wrong.

No, fakeraid does not know or care about the HPA.  It still stores its
metadata at the end of the disk, as it appears when its size is reduced
by the HPA, if there is an HPA.  Most systems do not have an HPA, but
some quirky ones do.  Both the bios and the Windows fakeraid drivers
leave the HPA intact if the system bios saw fit to make one.  A stock
Linux kernel does the same, but Ubuntu kernels default to automatically
unlocking the HPA, which moves the location of the fakeraid metadata
relative to the end of the disk, so dmraid can not find it.  Of course
it also enables the user to write to an area of the disk that the bios
very clearly marked as off limits.

Re: libata: implement on-demand HPA unlocking

[Alan Cox]

On Wed, 09 Feb 2011 14:36:22 -0500
Phillip Susi <psusi@cfl.rr.com> 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.

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.

> > "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.

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/9/2011 4:13 PM, Alan Cox wrote:
> Correct. The vendors however primarily used it for completely different
> things. Also trusting the BIOS is generally not a good idea.

I disagree.  Trusting the bios /generally/ is exactly what you should
do.  When it is known to be broken in specific cases, then sure, over
ride it, but /generally/ you should assume it knows what it's talking about.

>> 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.

I meant that the reports I have seen show the kernel prints listing the
size before and after the unlock, and they are always very close.

> 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.

That assumes that the bios is reserving the HPA for no good reason at
all and it is safe to ignore it.  This does not seem to be a good
assumption based on both the ATA spec and the behavior of Windows.  At
any rate, the decision to NOT unlock by default seems to have been made
years ago when libata was written, and certain distributions decided to
risk breaking compatibility with hardware that runs Windows just fine in
favor of not breaking upgrades from systems installed with the old ide
driver that did default to unlocking.

The discussion at hand is about a change made a few months ago that is a
good compromise between always unlocking, and never unlocking.  Both of
those have problems, so a good compromise can have the benefits of both,
and the drawbacks of neither.  Furthermore, it is already in the kernel,
so continuing to argue about whether it should have been done or not
seems a moot point.

Re: libata: implement on-demand HPA unlocking

[Alan Cox]

> years ago when libata was written, and certain distributions decided to
> risk breaking compatibility with hardware that runs Windows just fine in
> favor of not breaking upgrades from systems installed with the old ide
> driver that did default to unlocking.

The old IDE driver defaulted to unlocking based upon years of experience
in the real world. Jeff insisted on being different, and surprise
surprise everyone ended up setting distro defaults that were different.

> The discussion at hand is about a change made a few months ago that is a
> good compromise between always unlocking, and never unlocking.  Both of
> those have problems, so a good compromise can have the benefits of both,
> and the drawbacks of neither.  Furthermore, it is already in the kernel,
> so continuing to argue about whether it should have been done or not
> seems a moot point.

I disagree, and again you are still missing the entire point. For the
RAID stuff you don't care if we unlock, you don't need to care if we
unlock. You need to care about getting the raid tools figuring out what
geometry the raid creation was using.

Re: libata: implement on-demand HPA unlocking

[Tejun Heo]

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

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 02/09/2011 04:39 PM, Alan Cox wrote:
> The old IDE driver defaulted to unlocking based upon years of experience
> in the real world. Jeff insisted on being different, and surprise
> surprise everyone ended up setting distro defaults that were different.

What experience?  The only reason that I have heard for unlocking it is 
to maintain compatibility with the old ide driver which did so.  What 
reason does Linux have to access an area of the disk that the system has 
made clear it should not?  Aside from the upgrade case, I can not see 
any upside to this, only the downside of breaking on systems that work 
fine on Windows, because it does not disregard the platform request to 
leave that part of the disk alone.

>> The discussion at hand is about a change made a few months ago that is a
>> good compromise between always unlocking, and never unlocking.  Both of
>> those have problems, so a good compromise can have the benefits of both,
>> and the drawbacks of neither.  Furthermore, it is already in the kernel,
>> so continuing to argue about whether it should have been done or not
>> seems a moot point.

> I disagree, and again you are still missing the entire point. For the
> RAID stuff you don't care if we unlock, you don't need to care if we
> unlock. You need to care about getting the raid tools figuring out what
> geometry the raid creation was using.

What part to you disagree with?  That the compromise in place can have 
the benefits of both, but the drawbacks of neither?

I understand that dmraid could work around the problem, but there should 
not be a problem in the first place.  The system has asked that we not 
touch that part of the disk, so unless we have a good reason to do 
otherwise, we should honor that request.  Given that this is how the 
kernel has operated for years, I am surprised that we are rehashing this 
argument.  The other side of the argument that some distributions have 
settled on seems to be satisfied with the compromise of auto unlock iff 
a partition seems to use the protected space.

You seem to be saying that this compromise should not have gone into the 
kernel and instead, it should have just been patched to always unlock 
like some distributions have.  Why?  What advantage is there to always 
unlocking over auto unlocking only when it seems necessary?

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 02/09/2011 04:41 PM, Tejun Heo wrote:
> 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.

What problems?  Other than those caused by unlocking it in the first 
place, and then upgrading?

> 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,

Unless the other machine decides to change it, then it is bound to the 
drive.  It is possible that both machines will change it, but since most 
don't bother using the HPA, it tends to be preserved when moving from a 
machine that uses it to one that does not.

> 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

Why?

> 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.

Then why did you write a patch that seems to be a reasonable compromise 
between the two and will allow distros to stop diverging from upstream 
in this way, and are now arguing against that patch?

Re: libata: implement on-demand HPA unlocking

[Robert Hancock]

On 02/09/2011 06:35 PM, Phillip Susi wrote:
> On 02/09/2011 04:41 PM, Tejun Heo wrote:
>> 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.
>
> What problems? Other than those caused by unlocking it in the first
> place, and then upgrading?
>
>> 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,
>
> Unless the other machine decides to change it, then it is bound to the
> drive. It is possible that both machines will change it, but since most
> don't bother using the HPA, it tends to be preserved when moving from a
> machine that uses it to one that does not.
>
>> 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
>
> Why?
>
>> 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.
>
> Then why did you write a patch that seems to be a reasonable compromise
> between the two and will allow distros to stop diverging from upstream
> in this way, and are now arguing against that patch?

I'm inclined to agree. Unlocking HPA by default is opening up a 
potential can of worms and seems likely to cause regressions. This thread:

http://fossplanet.com/f10/host-protected-area-unconditional-disable-87925/

points out: "once HPA has been turned off a power cycle is needed to 
turn it back on. This can severely confuse another operating system when 
it finds the disk has changed size. In rare cases it can cause RAID 
cards to drop RAID sets on the floor thinking they are corrupt. All bad."

I don't see a case where unlocking HPA benefits us except in the case of 
upgrading from an older distro using IDE where HPA was being unlocked, 
or in the (vanishingly unlikely these days) case where the HPA is used 
to hide the drive's full capacity from the BIOS. The former case would 
be handled by the existing logic and proposed patch. The latter case can 
be handled with a module option. I don't see the benefit of playing with 
fire and shutting off HPA all the time.

Re: libata: implement on-demand HPA unlocking

[Tejun Heo]

Hello, guys.

On Wed, Feb 09, 2011 at 07:46:32PM -0600, Robert Hancock wrote:
> On 02/09/2011 06:35 PM, Phillip Susi wrote:
> >On 02/09/2011 04:41 PM, Tejun Heo wrote:
> >>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.
> >
> >What problems? Other than those caused by unlocking it in the first
> >place, and then upgrading?

The problem with pushing this type of seemingly smart workarounds is
that people gets tunnel visioned by their own narrow view of the
problem.

What happens if a drive is moved to another machine?  What about
hotplugging a drive?  What if partition detection code incorrectly
interprets a chunk of data in a RAID5 member as a partition table
(most partition tables don't have good protection against
misinterpretation)?

> >>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,
> >
> >Unless the other machine decides to change it, then it is bound to the
> >drive. It is possible that both machines will change it, but since most
> >don't bother using the HPA, it tends to be preserved when moving from a
> >machine that uses it to one that does not.

Many don't even use volatile setting and most happily override
whatever the current setting may be.  It just doesn't work.  These
BIOS features are designed with the mindset "If it works on this
motherboard and windows, we're done.  Hell with all other use cases",
which is quite different from what Linux should be aiming for.

> >>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
> >
> >Why?
> >
> >>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.
> >
> >Then why did you write a patch that seems to be a reasonable compromise
> >between the two and will allow distros to stop diverging from upstream
> >in this way, and are now arguing against that patch?

You've got it backwards.  The patch doesn't do anything for distros
which unlock by default.  On the contrary, the patch unlocks _more_ on
ones which didn't use to.  IIRC, debian didn't want to unlock by
default (the rationale was that they already had both ide and libata
userbases) and it seemed like a good enough tradeoff to avoid breaking
ide compatibility for most people.

Making the condition more intricate won't fix the problem.  It's just
gonna make it fail in more weird and convoluted ways.

> I'm inclined to agree. Unlocking HPA by default is opening up a
> potential can of worms and seems likely to cause regressions. This
> thread:
> 
> http://fossplanet.com/f10/host-protected-area-unconditional-disable-87925/
> 
> points out: "once HPA has been turned off a power cycle is needed to
> turn it back on. This can severely confuse another operating system
> when it finds the disk has changed size. In rare cases it can cause
> RAID cards to drop RAID sets on the floor thinking they are corrupt.
> All bad."
>
> I don't see a case where unlocking HPA benefits us except in the
> case of upgrading from an older distro using IDE where HPA was being
> unlocked, or in the (vanishingly unlikely these days) case where the
> HPA is used to hide the drive's full capacity from the BIOS. The
> former case would be handled by the existing logic and proposed
> patch. The latter case can be handled with a module option. I don't
> see the benefit of playing with fire and shutting off HPA all the
> time.

Hotplugging and being able to move hard drives between different
machines, and in general behaving consistently across different
hardware configurations have way higher priority than trying to avoid
confusing broken BIOSen or other operating systems in obscure
configurations.  Those problems are very rare to begin with (ubuntu
unlocks HPA by default!) and usually can be avoided by changing
configuration (or turning off HPA unlocking if it really comes down to
that).  It's just absurd to decide the default behavior based on those
fringe cases.

Thanks.

-- 
tejun

Re: libata: implement on-demand HPA unlocking

[Tejun Heo]

Hello,

On Wed, Feb 09, 2011 at 02:45:48PM -0500, Phillip Susi wrote:
> Then why did you have libata default to NOT unlocking it, which seems to
> be the correct thing to do?  When Ubuntu switched to libata they patched
> it to default to unlocking the HPA because the old ide driver did.  This
> seems wrong and causes breakage.  Tejun's patch seems to be a good
> compromise between the two choices: unlock if you think it will help,
> otherwise, don't, since it might hurt.

I don't think that patch supports your argument to begin with but even
if it did don't get too hung up on the fact that I (or anyone else)
did something contrary in the past.  I've done a lot of stupid and
horrible things and changed mind more times than anyone should care
about.

I thought it would be a good and safe compromise for distros which
don't want to unlock by default but look at where we are.  We just
ended up with failures which are more obscure.  Your proposed addition
will only push things further that direction.  It might not
necessarily be a bad thing.  Maybe the level of obscurity then goes
beyond certain level and we wouldn't have to care about that.

But much better solution seems to be exporting the bios size to others
and letting the ones which understand storage configuration better
deal with it.  At the block or libata layer, we simply don't have
enough information to make those decisions in a reliable manner.

Thanks.

-- 
tejun

Re: libata: implement on-demand HPA unlocking

[Alan Cox]

> What experience?  The only reason that I have heard for unlocking it is 

About ten years of distributions, drive hiding magic for old BIOSes and
other pain.

> to maintain compatibility with the old ide driver which did so.  What 
> reason does Linux have to access an area of the disk that the system has 
> made clear it should not?

It's unfortunate you won't listen but continue to spout stuff from a
standard no vendor, no OS and no product ever followed. ATA is not built
on strict adherance to formal standards, nor is the PC.

> What part to you disagree with?  That the compromise in place can have 
> the benefits of both, but the drawbacks of neither?

That there is any point doing anything but always unlocking.

> I understand that dmraid could work around the problem, but there should 
> not be a problem in the first place.  The system has asked that we not 
> touch that part of the disk

I see no point continuing this discussion if all you want to do is wave a
'standard' that isn't followed by anyone and breaks stuff and demand we
follow it. Always unlock in the kernel, make both sets of geometry
available via sysfs and then fix dmraid. It's an easy problem to solve
and because dmraid knows a lot about fakeraid stuff it also knows enough
to peer in various locations and figure out which to use - something that
the kernel quite intentionally does not.

Alan

Re: libata: implement on-demand HPA unlocking

[Bartlomiej Zolnierkiewicz]

On Thu, Feb 10, 2011 at 1:23 AM, Phillip Susi <psusi@cfl.rr.com> wrote:
> On 02/09/2011 04:39 PM, Alan Cox wrote:
>>
>> The old IDE driver defaulted to unlocking based upon years of experience
>> in the real world. Jeff insisted on being different, and surprise
>> surprise everyone ended up setting distro defaults that were different.
>
> What experience?  The only reason that I have heard for unlocking it is to
> maintain compatibility with the old ide driver which did so.  What reason
> does Linux have to access an area of the disk that the system has made clear
> it should not?  Aside from the upgrade case, I can not see any upside to
> this, only the downside of breaking on systems that work fine on Windows,
> because it does not disregard the platform request to leave that part of the
> disk alone.

I wish it was so simple.. HPA was originally used for accessing disk
area > 128GB (so default to unlock) on systems with buggy BIOSes and
then on some laptops vendors started to use it in _theirs_ Windows
versions for recovery area (so default to lock!), somewhere in between
fakeraid vendors came in to the game and finally we had conflicting
Linux defaults more as a result of premature deployment by some
distributions than a policy decision (since there were no feature
implemented to make a policy decision for).. oh and please do not
forget about distribution upgrades/downgrades -- not a common case in
Linux world but such things really do happen.. Do you see a problem
now?  You just cannot make a one policy nowadays and whatever policy
you decide on you're going to break some setups.. :-)  HPA policy is
system _and_ disk _and_ specific configuration dependent so there is
no way for kernel alone to get all different cases right.  The best we
can do is export all data points to user-space and let it & user deal
with the resulting mess..

Thanks,
Bartlomiej

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/10/2011 4:44 AM, Tejun Heo wrote:
> I thought it would be a good and safe compromise for distros which
> don't want to unlock by default but look at where we are.  We just
> ended up with failures which are more obscure.  Your proposed addition
> will only push things further that direction.  It might not
> necessarily be a bad thing.  Maybe the level of obscurity then goes
> beyond certain level and we wouldn't have to care about that.

Exactly.  With this additional refinement, it should push the failure
cases so far into the obscure that we don't really need to worry about
it, and there isn't anything that can be done about it anyhow without
causing worse problems.

> But much better solution seems to be exporting the bios size to others
> and letting the ones which understand storage configuration better
> deal with it.  At the block or libata layer, we simply don't have
> enough information to make those decisions in a reliable manner.

Then you are back to doing something that from the perspective of the
standards, the bios, and Windows, is wrong and at least in theory can
cause data loss.  Why would that be better than unlocking when there is
good reason to believe that it 1) won't cause data loss, and 2) is
necessary to access user data?

My personal preference would be to get the HPA and partition table code
out of the kernel entirely and leave it up to udev and friends, which
have the ability to recognize complex situations like the disk being a
fakeraid member, and choose to ignore the partition table on the
underlying disk entirely, but that doesn't seem likely to happen soon.

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/10/2011 7:46 AM, Alan Cox wrote:
> About ten years of distributions, drive hiding magic for old BIOSes and
> other pain.

So a few systems made over a decade ago used the HPA to hide the true
size of the drive from a broken bios, and it was a good idea for the OS
to unlock it?  How did Windows run on such systems?  That seems like a
radically obscure case for always unlocking.  Tejun's change already
fixes such a system anyhow.

Is there any other pain that makes unlocking a good idea?  Would any of
it still fail with Tejun's change?

> It's unfortunate you won't listen but continue to spout stuff from a
> standard no vendor, no OS and no product ever followed. ATA is not built
> on strict adherance to formal standards, nor is the PC.

Microsoft's OS follows it.

> I see no point continuing this discussion if all you want to do is wave a
> 'standard' that isn't followed by anyone and breaks stuff and demand we
> follow it. Always unlock in the kernel, make both sets of geometry
> available via sysfs and then fix dmraid. It's an easy problem to solve
> and because dmraid knows a lot about fakeraid stuff it also knows enough
> to peer in various locations and figure out which to use - something that
> the kernel quite intentionally does not.

Even if dmraid works around it, you are still left with:

1)  Possibly trashing data the bios put on the hd and told you not to touch

2)  Rebooting after running Linux leaves the drive unlocked, which
causes the fakeraid bios to complain that your raid is broken.  People
don't like that.

Re: libata: implement on-demand HPA unlocking

[Tejun Heo]

Hey, Phillip.

On Thu, Feb 10, 2011 at 01:47:48PM -0500, Phillip Susi wrote:
> On 2/10/2011 4:44 AM, Tejun Heo wrote:
> > I thought it would be a good and safe compromise for distros which
> > don't want to unlock by default but look at where we are.  We just
> > ended up with failures which are more obscure.  Your proposed addition
> > will only push things further that direction.  It might not
> > necessarily be a bad thing.  Maybe the level of obscurity then goes
> > beyond certain level and we wouldn't have to care about that.
> 
> Exactly.  With this additional refinement, it should push the failure
> cases so far into the obscure that we don't really need to worry about
> it, and there isn't anything that can be done about it anyhow without
> causing worse problems.

That's a big maybe and the failures would be far more obscure and
unpredictable.  Think about RAID5.  If we're gonna head that way, I
would rather just say we're already beyond the necessary obscurity and
leave things be.

> > But much better solution seems to be exporting the bios size to others
> > and letting the ones which understand storage configuration better
> > deal with it.  At the block or libata layer, we simply don't have
> > enough information to make those decisions in a reliable manner.
> 
> Then you are back to doing something that from the perspective of the
> standards, the bios, and Windows, is wrong and at least in theory can
> cause data loss.  Why would that be better than unlocking when there is
> good reason to believe that it 1) won't cause data loss, and 2) is
> necessary to access user data?

But as I wrote before, there are noticeable advantages to unlocking
unconditionally - regarding hotplugs, moving hard drives to different
machines and general unpredictability of BIOS behaviors, which are far
more important than the fringe downsides.  Hard drives changing sizes
depending on to which machine and when they're connected are simply
bad.  Confused linux systems are far more grave in my book than
confused BIOSen or whatever other operating systems.

Besides, as some distros (including ubuntu and openSUSE) are already
unlocking hard drives unconditionally, being smarter about auto
unlocking doesn't buy us much.  We need something which help fakeraid
work on those setups.

> My personal preference would be to get the HPA and partition table code
> out of the kernel entirely and leave it up to udev and friends, which
> have the ability to recognize complex situations like the disk being a
> fakeraid member, and choose to ignore the partition table on the
> underlying disk entirely, but that doesn't seem likely to happen soon.

I don't think that's gonna fly.  There are cases disks need to be
accessed directly by the kernel while userland is still not
operational.  The suggested solution where disks are always unlocked
and the alt size is exported via sysfs allows about the same
capability without the downsides of not unlocking HPA.  The whole disk
is always accessible and userland tools can choose between the two
sizes.

The problem is updating the tools.  Well, we can start by exporting
the alt size and not changing unlocking logic for now so that nothing
is further broken but the extra information is still available.  Down
the road, after the tools are all updated, we can flip the switch and
unconditionally unlock HPA and kill all the ugly workaround logics.

Thanks.

-- 
tejun

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/10/2011 4:13 AM, Tejun Heo wrote:
> What happens if a drive is moved to another machine?  What about
> hotplugging a drive?  What if partition detection code incorrectly
> interprets a chunk of data in a RAID5 member as a partition table
> (most partition tables don't have good protection against
> misinterpretation)?

I don't see how any of these cases are made worse by your change.  If
you move to another machine and it adds an HPA, then your change will
unlock it.  If you incorrectly interpret a chunk of data as a partition
table, then you incorrectly unlock ( this is exactly what I am to fix ),
but that isn't worse than always unlocking.

> BIOS features are designed with the mindset "If it works on this
> motherboard and windows, we're done.  Hell with all other use cases",
> which is quite different from what Linux should be aiming for.

I agree, but always unlocking seems to HURT that goal rather than help it.

> You've got it backwards.  The patch doesn't do anything for distros
> which unlock by default.  On the contrary, the patch unlocks _more_ on
> ones which didn't use to.  IIRC, debian didn't want to unlock by
> default (the rationale was that they already had both ide and libata
> userbases) and it seemed like a good enough tradeoff to avoid breaking
> ide compatibility for most people.

You can't unlock any more than always ;)

Ubuntu has dropped its patch to always unlock in favor of your upstream
change to unlock when it makes sense.  The net result is that it unlocks
less, but still sometimes unlocks when it should not with certain raid
setups.  Also this is not just a problem for fakeraid; mdadm raid setups
can run into the same problem.

> Making the condition more intricate won't fix the problem.  It's just
> gonna make it fail in more weird and convoluted ways.

If it fails less, then it is an improvement.

> Hotplugging and being able to move hard drives between different
> machines, and in general behaving consistently across different
> hardware configurations have way higher priority than trying to avoid

Your auto unlock change seems to address that issue just fine.

Re: libata: implement on-demand HPA unlocking

[Tejun Heo]

On Thu, Feb 10, 2011 at 01:58:58PM -0500, Phillip Susi wrote:
> > It's unfortunate you won't listen but continue to spout stuff from a
> > standard no vendor, no OS and no product ever followed. ATA is not built
> > on strict adherance to formal standards, nor is the PC.
> 
> Microsoft's OS follows it.

Try to do anything slightly advanced with BIOS RAIDs.  It works only
when you stay inside the pretty confined use case dictated by the
hardware/driver vendor and what's supported varies widely depending on
which BIOS RAID you're using.  Really, think about how they would
handle hot swap.

> Even if dmraid works around it, you are still left with:
> 
> 1)  Possibly trashing data the bios put on the hd and told you not to touch

Unlocking doesn't equal thrashing and if root wants to ignore BIOS
suggestions, root shall be able to.

More importantly, BIOSen having control over some part of disk never
works reliably.  It might have worked ten years ago when hardware
configuration never changed without intervening system resets and
POSTs.  These days, it's just not possible.  Hardware comes and goes
while the system is running and there's no way for BIOS to do anything
about it.

The only valid use case would be stuff like recovery partitions on
laptops and instant boot thingies on some motherboards.  Installation
tools seemed to deal with them well enough.

> 2)  Rebooting after running Linux leaves the drive unlocked, which
> causes the fakeraid bios to complain that your raid is broken.  People
> don't like that.

That's something BIOS writers should deal with.  Report it to them.
Distros can be nice and lock it again during shutdown sequence from
userland too but I don't think it's something which should dictate the
decisions.

Thanks.

-- 
tejun

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/10/2011 7:49 AM, Bartlomiej Zolnierkiewicz wrote:
> no way for kernel alone to get all different cases right.  The best we
> can do is export all data points to user-space and let it & user deal
> with the resulting mess..

Is it even possible to turn the HPA back on when udev runs dmraid?  I
suppose that would fix the problems with dmraid.

What worries me though is that while it seems that most systems so far
do not seem to store anything vital in the HPA so unlocking by default
does not cause harm, it is defined as a feature, not a bug, so future
systems can very well start storing vital data there, and then we really
will step in it by always unlocking.

Re: libata: implement on-demand HPA unlocking

[Alan Cox]

> Ubuntu has dropped its patch to always unlock in favor of your upstream
> change to unlock when it makes sense.  The net result is that it unlocks
> less, but still sometimes unlocks when it should not with certain raid

If you start the smart stuff then it also sometimes locks when it
shouldn't with devastating results for non technical users. I'd say
Ubuntu made a bad mistake on that one, but its their project so up to
them.

> > Making the condition more intricate won't fix the problem.  It's just
> > gonna make it fail in more weird and convoluted ways.
> 
> If it fails less, then it is an improvement.

No - not if the failure becomes harder to handle. It's like the
difference between debugging an app crash versus trying to work out why
some convuluted pile of Gnome desktop stuff has suddenely decided not to
stick up an authentication box this week. Clear, bounded, predictable and
replicable failure cases are good in the long term.

> > Hotplugging and being able to move hard drives between different
> > machines, and in general behaving consistently across different
> > hardware configurations have way higher priority than trying to avoid
> 
> Your auto unlock change seems to address that issue just fine.

No - because the drive may not even have a partition table on the other
OS.

Re: libata: implement on-demand HPA unlocking

[Tejun Heo]

On Thu, Feb 10, 2011 at 02:11:59PM -0500, Phillip Susi wrote:
> On 2/10/2011 4:13 AM, Tejun Heo wrote:
> > What happens if a drive is moved to another machine?  What about
> > hotplugging a drive?  What if partition detection code incorrectly
> > interprets a chunk of data in a RAID5 member as a partition table
> > (most partition tables don't have good protection against
> > misinterpretation)?
> 
> I don't see how any of these cases are made worse by your change.  If
> you move to another machine and it adds an HPA, then your change will
> unlock it.  If you incorrectly interpret a chunk of data as a partition
> table, then you incorrectly unlock ( this is exactly what I am to fix ),
> but that isn't worse than always unlocking.

RAID.  The partition based detection is flimsy by nature.  Block layer
doesn't have enough information to make the decision reliably.

> > BIOS features are designed with the mindset "If it works on this
> > motherboard and windows, we're done.  Hell with all other use cases",
> > which is quite different from what Linux should be aiming for.
> 
> I agree, but always unlocking seems to HURT that goal rather than help it.

I don't know.  I think I explained as well as I could and it seems the
biggest barrier to reaching agreement seems your attachment to BIOS
features/requirements, which I frankly can't understand or appreciate.

> You can't unlock any more than always ;)
> 
> Ubuntu has dropped its patch to always unlock in favor of your upstream
> change to unlock when it makes sense.  The net result is that it unlocks
> less, but still sometimes unlocks when it should not with certain raid
> setups.  Also this is not just a problem for fakeraid; mdadm raid setups
> can run into the same problem.

Okay, so Ubuntu switched.  Ah well, for most desktop users, that might
be better for now but I still don't think it's a good solution no
matter how much we try to augment it.  We simply don't have enough
information to make those decisions during device probe.

> > Making the condition more intricate won't fix the problem.  It's just
> > gonna make it fail in more weird and convoluted ways.
> 
> If it fails less, then it is an improvement.

In some sense maybe, but ask any self-respecting engineer, [s]he will
tell you the work kind of failures are the ones which happen once in a
blue moon in unpredictable manner.

> > Hotplugging and being able to move hard drives between different
> > machines, and in general behaving consistently across different
> > hardware configurations have way higher priority than trying to avoid
> 
> Your auto unlock change seems to address that issue just fine.

If it did that just fine, this thread wouldn't exist.  I think we just
should agree to disagree.  I'm not buying most of your arguments and
you seem to be doing likewise.

Thanks.

-- 
tejun

Re: libata: implement on-demand HPA unlocking

[Tejun Heo]

On Thu, Feb 10, 2011 at 08:32:35PM +0100, Tejun Heo wrote:
> In some sense maybe, but ask any self-respecting engineer, [s]he will
> tell you the work kind of failures are the ones which happen once in a
               ^^^^
	       worst
> blue moon in unpredictable manner.

-- 
tejun

Re: libata: implement on-demand HPA unlocking

[Alan Cox]

> What worries me though is that while it seems that most systems so far
> do not seem to store anything vital in the HPA so unlocking by default
> does not cause harm, it is defined as a feature, not a bug, so future
> systems can very well start storing vital data there, and then we really
> will step in it by always unlocking.

Lots of systems store lots of things they define as 'essential' in both
HPA and non HPA areas, I've seen uglies like laptops with a 2GB+ HPA
holding the windows reinstall for example.

Strangely enough the users often disagree on the subject, and also the
vendors tend to be sensible about what happens if it isn't there because
users do disk swaps when drives fail or as aftermarket upgrades.

Alan

Re: libata: implement on-demand HPA unlocking

[Alan Cox]

On Thu, 10 Feb 2011 14:20:43 -0500
Phillip Susi <psusi@cfl.rr.com> wrote:

> On 2/10/2011 7:49 AM, Bartlomiej Zolnierkiewicz wrote:
> > no way for kernel alone to get all different cases right.  The best we
> > can do is export all data points to user-space and let it & user deal
> > with the resulting mess..
> 
> Is it even possible to turn the HPA back on when udev runs dmraid?  I
> suppose that would fix the problems with dmraid.

You still don't get it do you.. the actual HPA is irrelevant to this,
utterly and totally.

Dmraid doesn't care about the HPA, it cares solely about the alleged
geometry of the device. It doesn't matter if the drive is unlocked or
not, it matters what magic number the kernel tells dmraid is the geometry.

Alan

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/10/2011 2:19 PM, Tejun Heo wrote:
> Unlocking doesn't equal thrashing and if root wants to ignore BIOS
> suggestions, root shall be able to.

There is a big difference between root choosing to override and the
kernel blindly doing it by default.  When you do it by default, then the
user creates a partition using the protected area, you trash whatever
the bios was storing there.

> That's something BIOS writers should deal with.  Report it to them.
> Distros can be nice and lock it again during shutdown sequence from
> userland too but I don't think it's something which should dictate the
> decisions.

The BIOS dealing with it isn't going to happen because of the "it works
with windows" malaise.  Userland handling it won't work when you sysrq-b
or similar.

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/10/2011 2:31 PM, Alan Cox wrote:
> If you start the smart stuff then it also sometimes locks when it
> shouldn't with devastating results for non technical users. I'd say

When?  Is there any specific case you can think of?

>>> Hotplugging and being able to move hard drives between different
>>> machines, and in general behaving consistently across different
>>> hardware configurations have way higher priority than trying to avoid
>>
>> Your auto unlock change seems to address that issue just fine.
> 
> No - because the drive may not even have a partition table on the other
> OS.

Huh?  Either the drive has a partition table or it doesn't.  It does not
matter which machine you plug it into or what another OS is doing.

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/10/2011 2:35 PM, Alan Cox wrote:
> Lots of systems store lots of things they define as 'essential' in both
> HPA and non HPA areas, I've seen uglies like laptops with a 2GB+ HPA
> holding the windows reinstall for example.
> 
> Strangely enough the users often disagree on the subject, and also the
> vendors tend to be sensible about what happens if it isn't there because
> users do disk swaps when drives fail or as aftermarket upgrades.

That is a very good example of something we should not break without
good cause.  Sure, you might just loose that press key X to recover boot
option, but we still should avoid breaking it.

Re: libata: implement on-demand HPA unlocking

[Alan Cox]

On Fri, 11 Feb 2011 13:18:50 -0500
Phillip Susi <psusi@cfl.rr.com> wrote:

> On 2/10/2011 2:31 PM, Alan Cox wrote:
> > If you start the smart stuff then it also sometimes locks when it
> > shouldn't with devastating results for non technical users. I'd say
> 
> When?  Is there any specific case you can think of?

Think about a raid volume where it is full disk and then the magic
autolocking crap guesses wrong, the volume goes partly inaccessible while
the box is running. Nasty mess.

> > No - because the drive may not even have a partition table on the other
> > OS.
> 
> Huh?  Either the drive has a partition table or it doesn't.

There are lots of table formats and tables in different locations. It's
not simple as you seem to think. One persons partition table is another
persons data block.

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/10/2011 2:32 PM, Tejun Heo wrote:
> RAID.  The partition based detection is flimsy by nature.  Block layer
> doesn't have enough information to make the decision reliably.

So are you suggesting that the decision be done via udev?  Perhaps that
is the best thing to do...

> I don't know.  I think I explained as well as I could and it seems the
> biggest barrier to reaching agreement seems your attachment to BIOS
> features/requirements, which I frankly can't understand or appreciate.

You don't understand why users get upset that Linux breaks their system?

>>> Hotplugging and being able to move hard drives between different
>>> machines, and in general behaving consistently across different
>>> hardware configurations have way higher priority than trying to avoid
>>
>> Your auto unlock change seems to address that issue just fine.
> 
> If it did that just fine, this thread wouldn't exist.  I think we just
> should agree to disagree.  I'm not buying most of your arguments and
> you seem to be doing likewise.

This thread exists because it does not address an issue that is not in
that list you mentioned, and then it is no worse than before the change
( where it never auto unlocked ).

Re: libata: implement on-demand HPA unlocking

[Phillip Susi]

On 2/11/2011 1:25 PM, Alan Cox wrote:
>> When?  Is there any specific case you can think of?
> 
> Think about a raid volume where it is full disk and then the magic
> autolocking crap guesses wrong, the volume goes partly inaccessible while
> the box is running. Nasty mess.

So a whole disk raid volume that was built with a patched kernel that
always unlocked and therefore invaded the HPA gets upgraded and now the
array won't activate.  So now we have the intersection of two rare
configurations ( most people use partitions rather than the whole disk
), plus an upgrade.  Valid, but quite rare, and of course, they would
get the same problem if they ran the unpatched Linus kernel right now.
Seems to me this rare failure is the fault of using the patched kernel
and invading the HPA in the first place.

So you either leave the kernel as it is today and have this one problem,
or you patch it to always unlock, and get several other problems.