From owner-cvs-all  Mon Aug 23 11:45:44 1999
Delivered-To: cvs-all@freebsd.org
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9])
	by hub.freebsd.org (Postfix) with ESMTP
	id D78D015A59; Mon, 23 Aug 1999 11:45:35 -0700 (PDT)
	(envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id EAA01679;
	Tue, 24 Aug 1999 04:45:21 +1000
Date: Tue, 24 Aug 1999 04:45:21 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199908231845.EAA01679@godzilla.zeta.org.au>
To: imp@village.org, phk@critter.freebsd.dk
Subject: Re: cvs commit: src/sbin/i386/fdisk fdisk.8 fdisk.c
Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

>Last time I tried to do this, I ran into the problem that I could not
>find out the disks' geometry.  At least what the BIOS thought the
>geometry was so that it would acutally create a bootable disk.
>FreeBSD lies for at least the UltraStor controllers because they
>reported what the disk said it was, rather than the "translated"
>numbers that the 34F used (and it was not possible, when last I
>looked, to disable this translation).

SCSI disks and controllers don't "use" any geometry.

FreeBSD begins with the geometry reported by the drives.  For SCSI disks,
I think this still usually has something to do with the actually geometry
(#cylinders and #tracks are correct, and #sectors is the average), but
this geometry is normally neither useful nor used.

FreeBSD then reads the partition tables and attempts to determine the
geometry being used.  This of course fails for disks without partitions
tables, so for new disks you usually have to type in the geometry that the
BIOS will use.

IIRC, the U34F normally reports a geometry of 64 tracks and 32 sectors,
and isn't very flexible (I vaguely remember a 128 track mode).  This works
OK for those huge 600 MB drives that we had a few years ago when U34Fs
were almost worth using, but runs into 1024-cylinder problems for >= 1GB
drives.

Similar problems occur for IDE drives.  The main difference is that the
geometry reported by the drive is also fake, and it used to be possible
to fake it in such a way that it was usable by BIOSes, and BIOSes used
it.  This was "fixed" when IDE drives became larger than 8.4GB.

These problems mean that "auto" on a slice can't be implemented properly
without solving the old problem of mapping drives to BIOS drive numbers
so that the table of BIOS geometries can be used.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message