[dm-devel] HPA unlock during partition scan of RAID components

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/04/2011 10:52 PM, Tejun Heo wrote:
> Hello,
> 
>> Well if it breaks under Windows, then we can't be faulted for
>> having the same results now can we?
> 
> Heh, let's just remove all hpa features and screw all the current 
> users which depend on them!

The only users that depend on them are those who originally installed
a version of Linux that did it wrong, and those can be handled with
proper distribution upgrade scripts, so yes, why not stop unlocking by
default, and leave it up to the distro upgrade scripts to enable the
override when backward compatibility requires it?

>> The other argument is that unlocking by default trashes whatever
>> data the bios was trying to hide in the HPA, and deviates from
>> the behavior of Windows.
> 
> On the former point, I don't think it matters. If the user doesn't 
> know what it is, [s]he can leave it alone. Maybe userland can do 
> something smarter if it knows the partition lives in hpa locked
> area, like not mounting it by default or hiding it from browser.

You don't think it matters that we are overwriting data that the bios
marked as reserved for its use only, and Windows respects that?  And
user land certainly can do things smarter, the question is what the
kernel default should be.

When upgrading, user land scripts can decide that the previous kernel
was doing it wring, and force the new kernel to continue doing it
wrong for the sake of backward compatibility, but I see no reason why
the default on new installs should deviate from Windows and refuse to
respect the will of the bios.

In other words, if a new install of Windows respects the HPA, then so
should a new install of Linux.

> On the point of not deviating from windows, I kinda agree and my 
> previous "let's just remove all hpa stuff" isn't all that
> sarcastic, but it really isn't that simple. On BIOS raid configs,
> the vendor controls both bios and driver and those drivers are very
> self contained. They implement all from bit pushing driver itself
> to raid stack and high level device management, and actually
> assumes that they have full control of the whole stack and do good
> number of crazy things. It would be surprising if no driver is
> unlocking hpa during driver init. And they do all sorts of crazy
> and broken stuff. Try to follow windows bios raid troubleshooting
> threads, it often ends up "umm... I lost everything and had to
> reinitialized the whole array from BIOS and reinstall".

Again though, it doesn't really have anything to do with fakeraid.  If
there is an HPA without a fakeraid, and Linux violates that HPA, then
Linux is causing damage that Windows does not.  The only reason that
fakeraid has anything to do with it is that for reasons unknown, there
seems to be a general overlap between boards that create an HPA and
boards that do fakeraid.  If fakeraid is out of the picture, and you
have a drive that has an HPA for whatever reason, Windows respects it,
and Linux trashes it.  That's not a good policy.

> If you have a great new idea to solve them all, please go ahead.
> I'll be happy to review.

I'm still looking for a problem that is not both caused by a broken
Linux policy in the past ( installing with an older kernel that
automatically unlocked ), and is solved by unlocking now.  The fact
that the broken Linux policy seems to mostly affect fakeraid users
does not justify continuing that broken policy.

In other words, Windows respects the protected area, so we should as
well, unless we have very good reason to believe that doing so would
cause loss of existing user data.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk60sqEACgkQJ4UciIs+XuLtuwCgg2fBXxE+PjW9i38jYvxFUrqa
qAMAn0+KBgzMnstTZpaOUKZXZeXQ3oU3
=106j
-----END PGP SIGNATURE-----