Re: libata: implement on-demand HPA unlocking

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

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.