HPA partition table check does not account for the possibility of a filesystem spanning the entire disk

[Colin Watson]

Eric Sandeen of Red Hat contacted me about a problem reported to the XFS list on upgrade from Ubuntu 10.10 (or earlier) to 11.04 (or later):

  http://www.spinics.net/lists/xfs/msg09177.html

He found a similar problem reported against ext4:

  http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/

We've worked out that this is due to this change to host protected area (HPA) handling in 11.04:

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380138

Now, reverting to the upstream default of honouring the HPA was absolutely the right thing to do here. We thought we'd covered all the likely upgrade failures by relying on Tejun Heo's upstream change, which checks whether the partition table extends beyond the HPA and if it does then it disables the HPA so you don't lose access to real data. However, it looks like we overlooked the case where there's no partition table, but instead there's a filesystem spanning the entire disk: this is the case in both the reports linked to above.

In addition to the kernel check, the kernel should ideally check for filesystems extending beyond the length that the block device would become if its HPA were honoured, and in that case it should disable the HPA.

[Colin Watson (cjwatson)]

The workaround, of course, is to boot with libata.ignore_hpa=1; but it would be better to DTRT by default.

[Andy Whitcroft (apw)]

This is a tricky one if we have to handle all filesystem types as it is not clear that we will definatly know the filesystem max block number, obviously the filesystem knows how much space there is inside.