lkml.org 
[lkml]   [2005]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: IDE HPA
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-09-04 01:46    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site