Re: IDE HPA

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> If the formula is to fix all the userspace apps to take into account a
> potential HPA, then eg. FDISK + SFDISK + Disk Druid et al should also
> be fixed.  Because if you create a partition spanning your entire
> disk, including the HPA area, and your boot files by some coincidence
> ends up in the HPA part of the disk, the BIOS won't be able to read
> them, and your system will not boot.  And if you fix those tools now,

The distribution vendors already put the boot area low down the disk to
handle a whole variety of problems like this and the 1024 cylinder limit
on old BIOSes. 

> what about users that use older Linux distributions?  They'll have a
> parade of problems coming to them with their new HPA-enabled disks
> because every userspace tool assumes that <BIOS sector count == Linux
> sector count>.

I work for a vendor. I get most of our IDE layer bugs. And do you know
HPA doesn't really feature. The broken locking does, the hangs on
changing down speed by CRC do, numerous fascinating platform specific
bugs do, people with cables backwards do. HPA doesn't. It just works out
for people.

> > It isnt the kernels fault if you compute from of end of disk rather than
> > from end of non reserved area is it ?
> 
> I agree that the entire disk should be visible under Linux.  But
> instead of fixing every userspace app that assumes <BIOS sector count
> == Linux sector count> (I'm guessing that's a lot), how about simply
> exporting the HPA as /dev/ide/hostX/busY/targetZ/lunA/hpa, next to the
> 'disc' device ?


A lot of applications assume Linux reported size == real disk size. It
also wouldn't solve the case of a file system that spans both inside and
outside the HPA.

Alan