David Burgess writes:

> Your disk geometry (for the initial install) must be (in C/H/S format)
> X/64/32 for disks less than 1Gig and X/255/63 for disks larger than 1G.

Robert Baron replies:

>I didn't do the math earlier.  If you disk is larger than 1Gig, look to 
>see if the 1542 is new enough to support "disks > 1 gig".  If this
>option is enabled then the geometry is, 255 heads and 63 sectors.
>
>NOTE: you can not tell netbsd that your disk had 255 heads.  Instead report
>you have 51 heads and multiply the number of cylinders (you calculated
>by dividing the capacity by 255*63) by 5.  This means that the offset to
>NetBSD (if non zero) would also be multiplied by 5.


Wouldn't it be a great idea if sysinst could automatically
compute a suitable lable and suggest that you use it?

I'm not sure I understand this correctly.  I _think_ there are two
separate issues:

	1) sysisnt wants to use the real geometry in the MBR.
	  This loses on Adaptecs; it needs to use the BIOS geometry.

	2) the fake Adaptec BIOS geomtetry can cause FFS  headaches when
	   newfs'ing big disks.

so, to try and recap, to make sure everyone working on sysinst
understands this :-)...

If we're installing on an Adaptec SCSI controller, then the SCSI BIOS
will always report the BIOS geometry, C/H/S, as X/64/32, for <= 1gig.
Newer Adaptec firmware has support for drives >= 1 gig.  or drives>=
1gig and with the > 1Gig support turned on, Adaptecs use a fake
geometry of X/255/63.

The problem here is the geometry NetBSD puts in the MBR.  If there's
no MBR on the disk, NetBSD has to write an MBR, and we have to get it
`right': the bootblocks use the MBR geometry and if we don't get it
right, the disk won't boot. (If there's already an MBR, presumably we
should use whatever geometry is there, so we don't screw up multiboots.)


But netbsd can also find the `real' disk geometry reported by a SCSI
mode-sense, and will recommend that you use that.  This is the WRONG
THING to use for Adaptec SCSI controller (and maybe scsi controllers
in general?); you need to use the BIOS geometry. (or, maybe, something
faked up from it).

fvdl suggests finding all BIOS geometries and letting the user pick
one.  That sounds OK to me; obviously if there's only one, it's easy:).


#2: Assume we have some sensible idea of what the BIOS geometry
of the target disk is.

The next problem is computing a disklabel geometry for the BSD
disklabel that doesn't upset newfs.  The X/255/63 geometries are OK.
The X/255/63 geometries are going to cause newfs to puke, because that
computes out to _huge_ cylinders, cylinder so big that the FFS is
going to puke trying to create cylinder groups and inodes.

The workaround for *this* is to fudge the geometry used the BSD
disklabel slightly, rather than just using the geometry in the MBR (or
the real disk). We divide heads by some suitable factor and multiply
cylinders by the same factor.  The prime factorization of 255 is
3*5*17, so 5 is a good candidate.  (This FFS issue could potentially
come up anywhere, but the only real place we've seen it to date is x86
BIOSes for SCSI disks).  As best I've followed the discussion, this is
only necessary for the >= 1gig case; the <1Gig case is fine.


OK. Here's the $64k question: if we do this fudge in the disklabel, do
we *also* need to do the same fudge in the C/H/S geometry in the MBR
too, or should it use the exat same values reported by the BIOS?


#3: how much of this drain-bamage is necesary on other platforms that
use MBR partitions -- e.g, Alpha, ppc, others?