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. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
