Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!ucsd!nosc!crash!jagat!rwhite From: rwhite@jagat.uucp (Robert White) Newsgroups: comp.sys.att Subject: Re: UNIX Formatting Limit Message-ID: <1991May12.232709.15395@jagat.uucp> Date: 12 May 91 23:27:09 GMT References: <1991May11.045012.4182@netcom.COM> Organization: My House (no organization to speak of) Lines: 92 Re: Large hard drive problem an a 386... The problem you describe has nothing to do with SVR4 per-se, it is a holdover from the IBM brain damage used to set the standard for the partition table. If you look in a DOS technical refrence manual you will discover that the number of bits set asside in the partition table for cylinder count is only capible of keeping a number in the range of 0-1023. Bigger hard drives are not allowed in the schema... The magic: Many hard disk controllers (read all intended for use with really big hard disks) have an option ROM which is evaluated durring boot and logically spliced into the system ROM. The feature ROM will contain a methodology for "remaping the physical geometry of your hard disk" (or some similarly obscure phrase). The technique goes something like this... (Consult your controller manual for exact procedures. If your controler is not capible of this activity you will need to get a different/better controler...) Use your system setup facility to indicate that the drive is either drive type zero (no drive) of drive type 1 (simple 10 meg drive) depending on the instructions contained in the controler manual. Reboot the computer using MS-DOS, Use the hardware boot (reset or power switch) and look for a diagnostic message telling you that there is an option ROM, note the address(es) presented. If your boot ROM does not give this information you can scower the controler manual for it. 8-of-10 times it will be C800. Load debug and execute a g=xxxx:5 where xxxx is the address from above (normally C800). This is the controller configuration subsystem. Something like *every* controller with an option ROM will have an interactive tool to do low level things to the drive starting at this address. You should have a simple menu in front of you. You will be given a choice which reads something like: "low level format and remap drive parameters" or "set drive geometry" or something. Pick that one and follow the directions... you will eventually be given the option to remap the geometry, pick a selection where the entire drive has less than 1024 cyls. Load up the UNIX Software and you are off... What you are doing: There are "special reserved areas" in the boot block for the hard drive which are outside the parition table and are not supposed to be overwritten by the boot program for the hard disk. the controler will write a few flag bytes in this area, which allows the controler to remember that it is to spoof the drive geometry. Durring the option ROM phase the controler reads this first sector and determines that spoofing is in order. It basicly pretends that the drive has either more heads per cylinder or more sectors per track, or both. Logicly this is like taking the extra magnetic media outside the first 1024 and using it to make more platters, or stretching the hub out into a bigger circle so there is more data in each revolution of the drive. The serious down side is that the software actually thinks that the hard drive has the new number of heads, tracks, etc. When every two or three cylinders are logically one cylinder, your drive scheduler will think it is parked over one cylinder when it is actually bouncing back and forth between several. Fortunately they will be adjcent to each other and most schedulers will write out the tracks in order from highest to lowest or lowest to highest as a matter of internal convience so the performance hit is not too severe. As a Caveat: Doing the g=c800:5 does cause some controlers to completely trash the boot block for the drive(s) in the system when spoofing information is involved. Most controlers assume that the rest of the block does not yet contain valid data and do nothing to preserve it. Doing this on an already installed system can make it unbootable. I have had this problem on one of the servers at work. *ALWAYS* do a backup of a system before you do this kind of low level stuff. On the system where this problem was encountered (I was adding a second drive) I used the first install disk for UNIX and broke out of the install script with a at the first prompt. Mounted the real(tm) root partition from the hard disk and used the rewrite-boot-files option of the partitioning commmand (the name of the command escapes me at the moment). It took me two hours to figure out this fix... The lesson: don't panic (if you have a backup how bad can it be? 8-). Thank you IBM. -- Robert C. White Jr. | I have moved my news reading activities rwhite@jagat