Date: Wed, 2 Apr 1997 07:57:00 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-hackers@freefall.FreeBSD.org (FreeBSD hackers) Subject: Re: wd and funky geometry (understood?) Message-ID: <199704021457.HAA04618@seagull.rtd.com> In-Reply-To: <199703171346.AAA13488@godzilla.zeta.org.au> from "Bruce Evans" at Mar 18, 97 00:46:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
It seems that Bruce Evans said: > > > The problem appears to an inconsistent use of geometry information > >for each drive. During IPL, the drive is INITed with parameters from the > >BIOS's disk parameter table. This makes sense as I can't imagine any > >*other* place from which to get the disk geometry (reliably). From > >boot() in /usr/src/sys/i386/boot/biosboot/boot.c: > >... > > However, in wdattach(), wdgetctlr() is invoked to get the drive's > >geometry. It does this by issuing an IDENTIFY command (i.e. READP) > >to the drive. The data returned by the command is interpreted as > >a wdparams structure: > >... > >Herein lies the problem: these parameters reflect "the default geometry of > >the device" (paraphrased from the ATA specification). However, the BIOS's > >geometry may *NOT* agree with the drives "default geometry". For example, > >the probe of my IDE drives yields: > > > > wdc0 at 0x1f0-0x1f7 irq 14 on isa > > wdc0: unit 0 (wd0): <Maxtor 7345 AT> > > wd0: 329MB (675450 sectors), 790 cyls, 15 heads, 57 S/T, 512 B/S > > wdc0: unit 1 (wd1): <MAXTOR LXT-340A> > > wd1: 321MB (659232 sectors), 654 cyls, 16 heads, 63 S/T, 512 B/S > > > >However, *both* drives have a BIOS geometry of 611/16/63. (Sorry, > >my ancient BIOS does not support "user configurable" geometries > >so this was the closest geometry I could find -- hence the reason > > What's the problem? The BIOS uses the fudged geometry that you told it, > but the FreeBSD driver knows better - there is no reason for it to use > a fudged geometry. *If* either (i.e. DOS vs. FBSD) lives alone on the disk, then fine. However, if they cohabitate, then they must agree on "what is where" on the disk. If DOS talks to the disk using a particular geometry, sets up it's partitions using that geometry, etc. then FBSD -- when it uses a different geometry -- must be sure to not stomp on those parts of the disk that DOS is using, etc. Does the drive (since that's the only "third party" involved here) guarantee that a sector that is *used* in one geometry is never regarded as "free" in another geometry (no, don't interpret this *literally*. my point is, if DOS uses a set of sectors in a given geometry, how is FBSD supposed to know that those sectors are "in use" when it adopts a different geometry to lay out it's slices?) > >Why is all this a problem? I don't *think* it causes any problems > >during IPL -- since the drive is INITed with the BIOS geometry > >during the boot and then switched to the "default geometry" > >during the attach/open. I think that the image loaded from the > >disk during boot is small enough that changes to the size/shape > >of the first track are safely ignored. (though, on second thought, > >I suspect this *can* screw you if your FBSD partition does not > >begin at the start of the disk! Comments?) > > > >However, sharing a partition might be a problem since DOS's > >FDISK (which you used to create the DOS partition) will talk > >to a disk shaped per the BIOS geometry. > > Of course you must use a consistently fudged geometry for everything > related to the BIOS. Yes, but when FBSD mounts a DOS "partition" that resides on the same disk as a FBSD "slice", how does it get to the "correct sectors" that the DOS partition was formatted to use since the drive is now configured for a different geometry? > >When FBSD takes over, > >the geometry of the disk is changed and track/cylinder boundaries > >can "move" (e.g., consider my case with a default geometry > >of 57 S/C vs. the BIOS's 63 S/C). > > The FreeBSD is unrelated to the BIOS. It doesn't even notice when > the boundaries move. See above. > >And, switching to/from DOS can screw you. Consider DOS and > >FBSD sharing wd0. FBSD reINITs the drive to use it's default > >geometry. Then, you mount a DOS partition FROM THE SAME DRIVE! > >The layout of the DOS partition expected the BIOS geometry > >yet the disk is now accessed using the FBSD geometry. > > No problem. If you mount the partition under FreeBSD, msdosfs > ignores everything related to geometries. If you reboot and > "mount" the partition under DOS, then the BIOS reinitializes the > geometry on reboot. Yes, I understand how/when the drive is reINITted. However, it doesn't explain how the two coexist AT RUN TIME. > >I suspect that LBA *could* be a redeeming grace. However, I don't > > Nope. > > >know enough about the *guarantees* within the drive to determine > >if a particular sector address will *allways* map to the same > >(PHYSICALLY EQUIVALENT) sector regardless of geometry (i.e., > >will sector "97" in a 611/16/63 geometry correspond to the > >exactl same physical sector when the drive is configured for > >790/15/57??) > > This is already guaranteed as follows: pick a geometry. Any physically > reasonable geometry will work with a modern IDE drive (but note that > BIOS geometries are usually not physically reasonable with modern BIOSes > for modern (non-small) IDE drives). Then issue a WDCC_IDC command to > tell the controller to translate using that geometry. Then do all > translations from blkno's to C/H/S values using that geometry. The Fine. So, for a DOS geometry, I "pick" 611/16/63. And, *DOS* faithfully uses that geometry for all disk accesses. Meanwhile, FBSD "picks" 790/15/57 and faithfully uses that geometry. But, FBSD doesn't *know* about the 611/16/63 that I "picked" for DOS! So, when *it* wants to go find a sector in that DOS filesystem that I've mounted, how does *it* get to the right sector -- given that the most recent INITIALIZE command specified the 790/15/57 geometry?? > driver could use LBA mode for modern drives, but that would complicate > the driver for little or negative benefit - it would still have to do > the translation for old drives. > > >[someone who really *knows* what they are talking about could probably > >determine the *real* effects of all this :-( ] > > Users get confused :-(. Well, from the followups to this original post, it appears "users" aren't the *only* ones who get confused! ;-) --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704021457.HAA04618>