Charles Hannum wrote:
> At boot time, before doing anything else, we do two BIOS calls for
> each disk (say, up to 16 disks).  The first loads the first block
> (MBR) of the disk, and the second gets the BIOS disk description.
> We store these (or maybe just the geometry and a hash of the first
> block) away.

> During autoconfig, when we find a disk, we read the first block,
> look it up in the table we stashed away, and if found use the
> geometry we got from the BIOS.  (If there are multiple matches with
> different BIOS geometries, we arbitrarily pick one and warn the
> user.)

The obvious likely failure case occurs when one have multiple disks
with completely zeroed-out first blocks.  (We fail in this case
already, of course, since fdisk has no way of intuiting the BIOS
geometry if there is no existing MBR.)  Writing out a cookie in the
boot block solves this problem robustly but is worrisome.  So the
options are:

	* Punt to the user in this case
	* Implement heuristics to handle this case, such as:
		- guessing at the BIOS's numbering of disks
		- figuring out which translated geometry matches the
		  size of the disk most closely
	* Implement the bothersome cookie-writing hack

Anyway, a 99% solution is noticeably better than what we have now, so
it doesn't matter much to me how we handle this case.

> This data is then used to calculate the default label.  If there is
> a label present already, we use that instead.

I am concerned about preserving the existing kernel-userland
interface.  fdisk has to use the BIOS geometry set the MBR features,
but the BIOS geometry is often undesirable for the disklabel as things
stand.  For instance, if your disklabel geometry has 255 heads and 63
sectors per track, a common LBA geometry, then FFS will demand a 4K
fragment size.  Right now, since fdisk is guessing at the BIOS
geometry from off in userland (based on what it reads from the MBR),
you can use a non-BIOS geometry in the disklabel and get away with it.