Alan Cox wrote: > Greg Felix wrote: > > Right. I get the output at bootup time. It reads that the HPA is > > 20MB. Which is exactly the size of how far off the metadata is in > > Linux (once the HPA is disabled). > > So your actual problem is nothing to do with the kernel or with the HPA > behaviour ? Whatever tool you are using for raid set up isn't reading > and processing the right fields. 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, 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>. > 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 ? _______________________________________________ Ataraid-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ataraid-list
