Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!paladin.american.edu!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (Terry Lambert)
Newsgroups: comp.os.386bsd.development
Subject: Re: fdisk
Date: 5 Feb 1994 12:45:16 GMT
Organization: Weber State University, Ogden, UT
Lines: 129
Message-ID: <2j04cs$b5d@u.cc.utah.edu>
References: <0hI0M_u00WB7EC5GkR@andrew.cmu.edu> <2ipjg4$mcq@explorer.clark.net> <EhIEZJu00VBLI_I2Zo@andrew.cmu.edu>
NNTP-Posting-Host: cs.weber.edu
In article <EhIEZJu00VBLI_I2Zo@andrew.cmu.edu> Timothy J Kniveton <tim+@CMU.EDU> writes:
>ack@clark.net (Eric S. Hvozda) writes:
>> do this. Do you have the geometery translated in BIOS? Did you use pfdisk
>
>it's a SCSI disk; there is no BIOS geometry.
It's a SCSI *controller* -- there *is* a BIOS geometry.
The problem is that the controller lies to DOS about the C/H/S values that
disk has so the disk can have the largest possible usable are under DOS
which has a short-sighted limit of 1024 cylinders.
This is called "translation", and the resulting geometry is "the DOS
geometry", or more formally, "the BIOS apparent geometry" -- what a
BIOS call asking for the geometry will return. This information is not
(easily) available to protected mode operating systems (like *BSD)
because most BIOS calls won't work in protected mode because BIOS
manufacturers hardly every consider anything other than the DOS market
when building Intel-based "PC" hardware (the big exception being the
IBM PS/2 protected mode BIOS).
Since most manufacturers implement this "lying" in software, not using
the BIOS makes it go away, and that's what you are seeing *BSD report;
if *BSD is "too dumb", it is "too dumb to be lied to".
Here is my post on translation and what to do about it until boot blocks
that pass BIOS apparent geometry and kernels that save the data off
and fdisk that reads it from the kernel and disklable ... become widely
available (you could have got this from the "minnie" archive that shows
up in announce about twice monthly):
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
============================================================================
c, h, s : untranslated geometry, as reported by AHA driver during boot.
c', h`, s': translated geometry, as reported by int13 ah=8.
Dc: Number of cylinders (using the translated geometry) reported
by fdisk under DOS.
The calculations:
Total_translated_cylinders = ( c * h * s) / ( h' * s')
Total_translated_sectors = Total_translated_cylinders * h' * s'
Total_translated_offset_sectors = Dc * h' * s'
Total_386BSD_translated_sectors =
Total_translated_sectors - Total_translated_offset_sectors
yield the information necessary for the disklabel for the 386BSD install
after the DOS install. Let's take a real example:
We have a Maxtor Panther P1-17S SCSI drive (1.778G unformatted).
We have an Adaptec 1742A in Standard mode with enhance translation turned
off (standard translation is turned on).
The translated geometry of the drive (reported by pfdisk.exe, int13 ah=8) is:
1024 Cylinders c'
64 Heads h'
32 Sectors s'
The actual geometry of the drive (reported by 386BSD on boot) is:
1778 Cylinders c
19 Heads h
86 Sectors s
The 'Total_translated_cylinders' is the number of translated cylinders the
disk would have if DOS didn't limit it to 1024. This ends up being:
( 1778 * 19 * 86 ) / ( 64 * 32) = 1418.58
To calculate 'Total_translated_sectors', we first round thi down to an
integer value, since non-integer cylinder numbers are meaningless. This
means we are going to lose some disk space (about 608k, to be exact):
1418 * ( 64 * 32) = 2904064
Now we need to know 'Dc': the number of DOS cylinders; for our example,
let's assume 180M. This works out to a nice round 180 cylinders for DOS
(the DOS fdisk program shows a start of '0' and an end of '179'). Using
this number, we determine the number of sectors into the disk where the
386BSD parition starts ('Total_translated_offset_sectors):
180 * ( 64 * 32) = 368640
Finally, we need to know how many sectors are going to be available to
386BSD, or 'Total_386BSD_translated_sectors':
2904064 - 368640 = 2535424
We now have all the information necessary for our disktab entry:
P1-17S|Maxtor Panther 1.78GB SCSI:\
:dt=SCSI:ty=winchester:se#512:nt#64:ns#32:nc#1418:\
:pa#????:oa#368640:ta=4.2BSD:ba#4096:fa#512:\
:pb#????:ob#????:tb=swap:\
:pc#2535424:oc#368640:\
:pd#2904064:od#0:\
:pe#????:oe#????:te=4.2BSD:be#4096:fe#512:\
:pf#????:of#????:tf=4.2BSD:bf#4096:ff#512:\
:pg#????:og#????:tg=4.2BSD:bg#4096:fg#512:\
:ph#????:oh#????:th=4.2BSD:bh#4096:fh#512:
Calculation of ???? values is based on how you want to divide up the disk
partitions. Partitions e-h are optional depending on the configuration
chosen by the user, with the exception that the total of pa, pb, pe, pf, pg
and ph can not exceed the value of pc, and that ob = oa + pa, oe = ob + pb,
of = oe + pe, og = of + pf, and oh = og + pg.
The values nt, ns, nc, oa, pc, oc, pd, and od should all be obvious in
their derivation from:
Total_386BSD_translated_sectors
Total_translated_offset_sectors
Total_translated_cylinders
h'
s'
============================================================================