On 11/4/2011 11:52 AM, Tejun Heo wrote:
Could you clarify what issues you refer to? Moving a drive to
another machine?
Yeah, that or hotplugging, or changing BIOS config, updating BIOS,
and, some (rare) BIOSen even fail to set up things consistently across
reboots.
I'm asking for a clarification not just a restatement. What problem
occurs when you move a drive to another machine, or hotplug the drive?
Exposing alt size should be enough for md/dm no matter how hpa is
setup.
So you are saying that mdadm should store the metadata for 0.9 and 1.0
relative to the locked end of the disk, even if it is currently
unlocked? I suppose then grub also will need to be able to detect if
the disk has been unlocked and adjust to using the locked size.
Being able to defeat the heuristic would help, but I still don't see
why the heuristic should be implemented in the kernel instead of
user space?
Because sans raids, it was good enough and doesn't recent md's have
metadata at the beginning anyway?
It isn't about whether it is good enough or not, it's about whether the
kernel should be using heuristics to make decisions, or leaving it up to
user space, where distros can come up with all kinds of complex logic to
handle all of the goofy cases. You complain that the block layer does
not have enough information to get it right, so why not let user space
decide, where it has access to all of the information it needs.
The thing is that you have your problem, and other people have other
issues w/ HPA. At this point, it's a misfeature abused by some silly
BIOSen mostly for silly BIOS raids. I think we should expose the most
we can to our users and if some BIOSen are screwed on soft reboot,
well, just accept it or turn off HPA unlocking manually.
It is actually not used FOR the bios raid. The bios is using the HPA
for unrelated reasons and it just happens that unlocking it breaks the
bios raid ( and mdadm with format 0.9 or 1.0 ).
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
