[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]