Date: Sun, 16 Mar 1997 19:23:26 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <199703170223.TAA16670@seagull.rtd.com> In-Reply-To: <199703162244.JAA17242@godzilla.zeta.org.au> from "Bruce Evans" at Mar 17, 97 09:44:21 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> No, the probed geometry is used for everything in the driver. > > > >Yes, that's what it appears to be. Except that the BIOS geometry is > >used during boot (at least in the 2.1 stuff). > > Booting is not part of the driver :-). Yes, I was just trying to stress the point that the geometry used during BOOT is the geometry established by the system ROMs/BIOS and that this can be different from the geometry used by FBSD (and, in my case, it IS!) > >> The geometry read from the label is not used by the driver (except in > >> `#if 0' code). It is normally only used by fdisk. newfs ignores it by > >> default. > > > >How does fdisk use it? Just to determine where cylinder boundaries > >exist? (i.e. so partitions are an integral multiple of cylinder size?) > > fdisk presents it as a default if the disk doesn't already have a > (reasonable) partition table on it. This seems to mainly confuse > users :-(. It later uses the geometry that the user set or accepted > to write the CHS values. Garbage geometry -> garbage CHS values -> > unbootable partitions and probably a different garbage geometry for > the default next time. > > >> The BIOS geometry is not used either, except in some kludgy cases > >> involving drives that don't report their geometry (old MFM drives). > > > >Again, the IPL stuff comes from the disk using the BIOS/"system ROM" > >geometry, right? > > What's IPL? Sorry... Initial Program Load :-( Easier for me to think of that than "boot"... > No, FreeBSD doesn't use the geometry reported by the BIOS > except to print a table of BIOS geometries when it is booted with -v, > and in some kludgy cases (see above). It doesn't know the correspondence > between BIOS drives numbers and FreeBSD drive names, so it can't look up > its table of BIOS drive geometries to get the BIOS geometry (if any) > corresponding to each FreeBSD drive. The point I was making (in a followup post) was that using the IDENTIFY command, you can get the geometry that the disk is currently using (though the wdparams struct currently isn't big enough to reference that particular set of parameters -- they are about 110 bytes into the parameter block returned by the IDENTIFY command). Instead, the attach currently examines the *default* geometry for the drive and uses that! So, if the BIOS has set the drive up with one particular geometry and gone through boot(), the attach() could inquire and *preserve* that geometry instead of resetting it to the "default" geometry that the disk manufaturer happened to pick... > >No one (with the exception of fdisk?) *should* need to know the real > >geometry, right? And, it could possibly be argues that fdisk/newfs > >only "need" to know it for "performance" reasons, right? > > Yes. No/yes. fdisk needs to know if for constructing bootable MBRs. Ah, OK. But, otherwise it should just be a performance hack, right? --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703170223.TAA16670>