Re: [RFC] ATA host-protected area (HPA) device mapper?

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

 



Jeff Garzik wrote:
As I just mentioned on linux-ide in another email:
libata should -- like drivers/ide -- call the ATA "set max" command to fully address the hard drive, including the special "host-protected area" (HPA). We should do this because the Linux standard is to export the raw hardware directly, making 100% of the hardware capability available to the user (and, in this case, Linux-based BIOS and recovery tools).


Yay for exposing absolute potential functionality; yay for recognizing the havok possible, and proposing strategies for channeling that possibility.

However, there are rare bug reports and general paranoia related to presenting 100% of the ATA hard drive "native" space, rather than the possibly-smaller space that the BIOS chose to present to the user.


I've grepped through several old discussions of HPA handling, and it doesn't seem like everyone has the same idea of exactly what this will do, possibly because of the delta in BIOS behavior over original design restrictions.

My thinking is that [someone] should create an optional, ATA-specific device mapper module. This module would layer on top of an ATA block device, and present two block devices: the BIOS-presented space, and the HPA.

Such a module would make it trivial for users to ensure that partition tables and RAID metadata formats know what the BIOS (rather than underlying hard drive) considers to be end-of-disk.

Comments?  Questions?  Am I completely insane?  ;-)


Tools with which to lay waste to systems, or save them.

What I like about your proposal is that it doesn't go back to "Do we blow away the HPA or reserve it?"; you suggest conserving both options. Make the kernel aware of the existence of the HPA, and thereby the whole capacity of the disk, and simultaneously of what it should see and expose for usage 'safely'. Doesn't sound insane to me; it sounds like you're planning on [having someone] teach the kernel to respect the actual disk limitations.

Whether the implementation will be sane ... 'nother story. :) Thence the question of teaching userspace to sanely use what is exposed, though if the 'old' (non-HPA) space is presented, it shouldn't be a hard reorientation. Would we be talking about a new sysfs entry parallel to the existing information? If I understand it right -- and I might not -- the HPA doesn't get included in the partitioning schemes, because it is protected. Even nuking the disk will/should bypass it. So the system will tend to ignore it under normal conditions, until you decide to get fancy and trip over its shadow. So making the kernel aware that this disk has this spot that must be respected should be a no-brainer. What better way to make the kernel aware of it, than by acknowledging it as a block device among other block devices? It just needs a good molly-guard to cover the respect portion of the problem.

Of course, I don't hack ATA, so my opinions may have limited validity after a certain level of specificity. I can always be enlightened as to why you really are insane. ;)

    Jeff


Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux