Re: libata: implement on-demand HPA unlocking

[Phillip Susi <psusi@cfl.rr.com>]

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.