Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!think.com!ames!agate!tfs.com!tfs.com!julian
From: julian@tfs.com (Julian Elischer)
Subject: Re: DOS and 386BSD (and NT and OS2)
Message-ID: <1992Oct16.043347.3567@tfs.com>
Organization: TRW Financial Systems
References: <1992Oct15.025722.15943@fcom.cc.utah.edu> <1992Oct15.081904.20697@ntuix.ntu.ac.sg> <1992Oct15.171833.25427@fcom.cc.utah.edu>
Date: Fri, 16 Oct 1992 04:33:47 GMT
Lines: 175
In article <1992Oct15.171833.25427@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>
>The translation is done by the disk BIOS *on* the controller, or it may be
>done by the drive itself. You don't use the BIOS for access, you don't
>get translation.
Actually, I think the translation is performed on the controller.
The disk driver in 386bsd actually resets the controller to use the
figures in the disklabel, but before it can get the disklabel it
has to guess at what translation the controller is set to.
It does this by assuming that the last block in a partition is also
the last block in a (translated) cylinder and from that, it can deduce
the number of heads etc. with that information it can load the
disklabel and then it resets the controller again to use whatever
geometry is in the disklabel.
>
>The limited case of 386BSD working on a drive without translation "turned
>off" is based on the assumption that the translation is linear -- ie:
>sector offset 321 is sector offset 321 regardless of translation, where
>n=321, and being valid for all n.
>
>There is a probe request (which not all controllers support!) that is done
>to ask the controller the disk's geometry. This is because the raw driver
>used in 386BSD doesn't use the BIOS (for reasons which should be obvious)
>and talks to the controller directly -- thus there is no such thing as a
>translated geometry as far as 386BSD (or any other non-BIOS OS) is
>concerned.
As I said above, the first access that the kernel does actually be in
translated mode. If you put translated parameters into your disklabel
it should continue to run in translation mode for all your work and
no-one would be the wiser (may be a bit slower). I think that in a
translating controller, the translation is done whether or not it's the
BIOS that is making the requests. Non translation is often only a case
of 1:1 translation.
> Without this, instructions to the controller for "translated"
>addresses not going through the "lookup" code (the BIOS) would fail.
If the translation is in hardware as I think, it would succeed.
>
>> The real geometry of the IDE disk is that of variable number of
>>sectors for each cyclinder, to get the maximum number of bytes.
>
>What you are talking about is a uniform rotational bit density as you go
>out from the hub. Many, many SCSI drives do this as well. This type of
>harsware translation is acceptable, as the only thing it messes up is
>seek latency calculation; this is not the same as a 4 head disk saying
>it has 64 heads.
>
>>I do not think that there is any OS that can handle varaible sector number so
>>the disk controller must convert the variable sector number to a linear number.
There are experimental filesystems being built to do this.
>
>AmigaDOS, the MAC "Finder", and VMS aren't OS's, then. 8-). In general,
>you are correct that there is "translation" going on. The difference is
>that it is in hardware, not the BIOS on the controller. Thus the translation
>is "invisible" to the software (although it does cause UNIX to mis-guess
>the inter-cylinder seek latency, underestimating it closer to the hub and
>overestimating it further away. It also causes the sector-to-sector seek time
>to be erratic, since now a seek is potentially involved. This can cost the
>time for one rotational latency on a read of two "adjacent" sectors). Usually
>the controller will take seek latency into account to precompute the
>rotational latency delay of a sector-sector read crossing a cylinder boundry
>doesn't cause a missed rotation; thus you only pay for the seek itself. At
>a maximum, this should cause about a 6% performance degradation.
>
>>The input parameters are the number of sectors per head, and number of heads
>>per cylinder.
>
>Right, and the number of cylinders. As long as this agrees between BIOS and
>direct access to the controller hardware, there isn't a problem. IDE generally
>uses the BIOS routines to perform "soft" translation, and this breaks the model.
>
well I don't think this is correct.. as I said before, the very first seek
the kernel does is in translated mode and it has to read the bootblock to
work out what the translated geometry is, so it can find the disklabel.
>>Theoretically, we can just choose any geometry on the bios, and it will work.
>>Provided your bios/software know the geometry that you store your data in.
>>I did this on a Western Digital 40Mbyte hard disk.
>
>This is a good point: If you have translation enabled, and it isn't linear
>(a sequential increase in head/cylinder increment yields adjacent sectors),
>the "mtools" on 386BSD will never be able to access your DOS partition, no
>matter what contortions are involved.
Or BSD4.2 FS!
>
>One of the major points here is that 386BSD only *sometimes* uses the BIOS;
>this during initial boot stages only.
>
>>However the IDE controller may allow software to read a recommended geometry,
>>which may be different from the BIOS setting(in CMOS RAM). DOS still works
>>because of the above reason.
>
>It does. This is the 386BSD problem: the translation is "soft". The reason
>DOS still works is it only uses the BIOS to access the disk.
No, iI think the translation is on the disk, (IDE.. controller = *nop* )
If the translation were in the BIOS then the first read to find the
disklabel would always fail, because the read to find the disklabel is
made using translated parameters.... hmmm I have ESDI,
I wonder if that is why I'm disagreeing with you.. has anybody been
able to get a translated IDE to work, if so, then the translation
must be in the hardware, (the same as the ESDI).
In any case, if the translation WERE in the BIOS then the new bootblocks
would still be ok, but the kernel would have to load REAL geometry
from the end of teh BIOS partition entry (I guess that's ok, nothing
else uses that information)
>
>>The problems come because of the mismatch between BIOS and disklabel
>>geometries.
>
>Exactly right. The "disklabel" program runs under 386BSD, which uses the
>"real" (potentially hardware translated but *not* software translated)
>geometry, since it accesses the disk through a 386BSD device (/dev/wd0d).
>
>>However DOS and 386bsd can still co-exist in this circumstances. Just instruct
>>the OS boot manager to load the appropriate partitions calculated using the
>>BIOS informations, converted from the disklabel info.
aha, maybe he means that by puting in untranslated figures in the ...
no that wouldn't work.. hmmm
>
>Now *I'm* confused; are you saying this will allow the second stage boot to
>know where the physical 386BSD partition starts from the translated data in
>the partition table? I would still think the second stage of booting would
>fail on a soft-translated drive, since the partition table is recorded in
>the soft geometry.
>
>>I have worked with 200Mbyte Conner, 200Mbyte Maxtor, 120 Mbyte Maxtor.
>>
>>I have another 240mbyte quantum pro IDE, but I believe I can install the DOS
>>as well, but I must have the OS-BS software. Otherwise, it will surely fail.
If I could find a translated IDE drive I could answer this one way
or the other in about 2 minutes flat.
One way would be to make two partitions pointing at the same block,
one in translated mode, and one in real, then the boot code could be
changed to look for a different OS_id so it would use a different
set of figures from the kernel (yuk)
>
>I *really* question the assumption that loading the first half of the boot
>code is sufficient here. You should actually be able to do this same thing
>with the Julian's code, which reads the kernel in using BIOS routines; I
>*still* think there would be a problem reconciling the physical location of
>the 386BSD partition for the 386BSD kernel; so even with Julian's code, a
>hard-coded location would be required for 386bsd to find and mount /.
>
>Once we get this hammered out, we should have a "the way things work"
>document that will be useful to everyone.
with the new fdisk program I just posted, we should be able to
test it easily.
>
>
> Terry Lambert
> terry@icarus.weber.edu
> terry_lambert@novell.com
>---
+----------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / On assignment
| / \ julian@tfs.com +------>x USA \ in a very strange
| ( OZ ) 2118 Milvia st. Berkeley CA. \___ ___ | country !
+- X_.---._/ USA+(510) 704-3137(wk) \_/ \\
v