Re: IDE HPA

[Jeff Garzik]

Peter Jones wrote:
> So where would you envision this code to check the partition table, the
> HPA/host default disk size, and guess how things should be set up?
>
> > From a userland perspective, it's very difficult to let users know
> they'll be screwing themselves by partitioning the entire disk, so we
> really should be leaving HPA enabled if the protected area is indeed not
> for consumption.
>
> Also, the heuristic is harder than this -- if we reexamine the fakeraid
> case, then it's clear we have to look for raid metadata, figure out if
> the raid includes stuff inside the HPA or not, and then if it doesn't we
> don't care -- but that's assuming there _is_ raid metadata.
>
> Long term, many people hope, possibly unrealistically, that we'll be
> able to write out raid metadata for people creating raids on cards which
> support fakeraid, and have the BIOS grok it appropriately.  So in that
> case, we may well have a blank (or garbage) disk, and we can't check the
> partition table or any raid metadata.  Correct me if I'm wrong, but I
> don't see a simple heuristic for this case.
>
> (as a side note, I know one user who, at OLS, noticed we fail to
> re-initialize HPA after unsuspend, so on at least t40 the disk gets
> smaller when you suspend.  This may or may not be fixed, I haven't
> checked.  But it's one more sort of pain we get into by disabling it,
> whether justified or not.)

It seems to me that one should write an ATA-specific Device Mapper 
driver, which layers on top of an ATA disk.  The driver obtains the 
starting location of HPA, then exports two block devices:  one for the 
primary data area, and one for the HPA.

For situations where we want the start Linux philosophy -- Linux exports 
100% of the hardware capability -- no DM layer needs to be used.  For 
situations where its better to treat the HPA as a separate and distinct 
area, the DM driver would come in handy.

This follows the same philosophy as fakeraid (BIOS RAID):  we simply 
export the entire disk, and Device Mapper (google for 'dmraid') handles 
the vendor-proprietary RAID metadata.

	Jeff


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