UNIX Formatting Limit

Robert White rwhite at jagat.uucp
Mon May 13 09:27:09 AEST 1991


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 <del> 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 at jagat           <Home |  not directly related to my job off of my
rwhite at nusdecs         <Work |  employers machine.  Please use "jagat"
"Like most endevors, life is seriously over-advertised and under-funded"



More information about the Comp.sys.att mailing list