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 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. 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". So... um... I don't know. The dual size thing was the best solution that I know of (don't remember who came up with it first) and at least some of the ATA people seem to agree with it. Anyways, I don't think we're making any useful progress in this thread, so this probably will be my last message unless something new comes up. If you have a great new idea to solve them all, please go ahead. I'll be happy to review. Good luck. -- tejun -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
