Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!know!cass.ma02.bull.com!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!tfs.com!tfs.com!julian From: julian@tfs.com (Julian Elischer) Newsgroups: comp.unix.bsd Subject: Re: 386BSD and IDE drives Message-ID: <1992Sep24.053902.6861@tfs.com> Date: 24 Sep 92 05:39:02 GMT References: <1992Sep23.212547.15460@fcom.cc.utah.edu> <19r0h6INNp42@aludra.usc.edu> <1992Sep24.022400.19483@fcom.cc.utah.edu> Organization: TRW Financial Systems Lines: 84 In article <1992Sep24.022400.19483@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >In article <19r0h6INNp42@aludra.usc.edu> eddy@aludra.usc.edu (George Edmond Eddy) writes: >>terry@cs.weber.edu (A Wizard of Earth C) writes: >> >>> I personally wouldn't buy an IDE because of geometry translation, >>>and there's one Maxtor SCSI drive, so far, in the same boat. I like the >>>UFS caching and optimization to actually result in a speedup, and it >>>can't on a geometry translated drive (see my other tirade 8-)). >> >>this would have been really cool to know before i plopped down $400 >>on an IDE, i would have come up with the extra $100 for the scsi >>controller, and went with that. >> >>Does the geometry translation problem in the other triad just result >>in a loss of intended performance gains, or can it result in freaky >>things happening to files and filesystems? > >The only time it acts "funny" is if the translation is used at one time >but not another -- for instance, 386BSD. > >The inital program load (IPL) code is from ROM and uses BIOS -- so the >geometry translation is in effect. Later, the "real" boot loader loads >the kernel using BIOS -- still no problem. Then the kernel takes over >in protected mode -- problem. Because the kernel has a driver which >probably ignores translation (which is generally a function of the BIOS, >although not in every case, ie: the Maxtor SCSI drive), the location >for paging and so on is not the load location. In addition, you may find >that during install from a floppy that the boot information could be >written to a location on the hard disk that happened to cause it to boot... >but that the translated boot information locates to somewhere in the middle >of the untranslated disk. You will run fine until you accidently overwrite >your boot information and it "mysteriously" quits booting. > >A lot of this can be alleviated by picking the user defined drive type and >entering the correct geometry as part of the CMOS setup. You of course >have to be able to *find* this information out, however. > >The other common problem is when you try to "partition" the drive. Since >the master boot record and partition table are at the front of the disk, >giving 386BSD the whole disk works (because sector 0 cylinder 0 usually >translates to the same location as it's untranslated value), but partitioning >doesn't work (because the translated address of the partition is not the >same as the untranslated address because it occurs at an offset greater than >0). This is also fixed by the "user defined drive type" fix. > >The problem with the "user defined drive type" fix is that you probably >wouldn't be doing geometry translation unless you needed it... which means >more than 1024 physical cylinders on a drive (anyone ever wonder why MFM >disks can only have up to ~130M on them? No geometry translation to let >them pretend that they have 1024 or less cylinders). > >Geometry translation is DOS's way of breaking the 1024 cylinder boundry... >beware of large drives that let DOS use the whole disk! > >Since DOS can't access cylinders past 1024, this means a DOS partition >would have to be before that -- thus either reducing the usable disk space, >or making the 386BSD partition the second one rather than the first. A >problem in asboot.c means that not having the 386BSD partition first can >mean it won't work. > >One of the most hilarious presentations I ever sat through was by a company >that tried to sell us "disk optimizer" software to "make the files >contiguous for faster access, reduce seek time, and practically eliminate >delays from rotational latency" -- right after selling us machines with >IDE drives in them. Since they were for DOS, I really didn't care of the >drives were IDE or not. My problem was with the company: either they were >stupid or they thought we were, either of which is reason enough to not do >business with them again. > >Now I wouldn't buy an IDE drive at all, since I expect to eventually install >386BSD on all machines in unlocked offices. 8-). 8-). > > > Terry Lambert > terry_lambert@npd.novell.com > terry@icarus.weber.edu >--- >Any opinions in this posting are my own and not those of my present >or previous employers. >-- >------------------------------------------------------------------------------- > "I have an 8 user poetic license" - me > Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial >-------------------------------------------------------------------------------