[330] in linux-scsi channel archive
Re: BT-946C, MIC-3243, disk geometry and booting
daemon@ATHENA.MIT.EDU (Drew Eckhardt)
Sat Jul 8 14:47:21 1995
To: J.H.N.Chin@reading.ac.uk
cc: linux-scsi@vger.rutgers.edu
In-reply-to: Your message of "Fri, 07 Jul 1995 18:36:33 BST."
<199507071736.SAA04775@suma3.rdg.ac.uk>
Date: Sat, 08 Jul 1995 02:37:12 -0600
From: Drew Eckhardt <drew@poohsticks.org>
In message <199507071736.SAA04775@suma3.rdg.ac.uk>, J.H.N.Chin@reading.ac.uk wr
ites:
>First a thank you to everyone who answered my previous question about
>PCI SCSI controllers. I have ended up getting a buslogic BT-946C
>controller and a Micropolis 3243 4GB drive. After a little fiddling
>with IRQs on the motherboard, it seems to be working happily although
>the machine locks up under DOS when I try to use the BTFDISK utility.
>
>Now I have a question about disk geometry.
>
>When I run fdisk ("v1.5b" or "v2.0d (>2GB)") on the drive, I get:
>
> Gilgamesh:~# fdisk /dev/sdb
> You must set heads.
> You can do this from the extra functions menu.
>
> Command (m for help):
>
>The latest sun format.dat file that I found on the sun-manager's archive
>gives:
>
> disk_type = "MICROPOLIS 3243-19" \
> : ctlr = MD21 : fmt_time = 9 \
> : ncyl = 4139 : acyl = 2 : pcyl = 4141 \
> : nhead = 19 : nsect = 106 : rpm = 7200 : bpt = 63282
>
>from which I infer that I should set:
>
>heads = 19
>cylinders = 4141 (4139 ?)
>sectors = 106
No. There is absolutely no connection between the physical geometry of
the drive, and what FDISK wants.
>Is this okay?
If you don't care about DOS, don't worry about it. If you don't care
about accessing beyond the first 1/8 of the drive for booting kernels,
and don't care about LILO headaches, don't worry about it. Other wise,
use whatever dparam.com says DOS thinks the geometry is.
>I know the README says it isn't wanting the real
>cylinders, etc, (which is just as well since the spec says it
>has 3659 cylinders) but would be interested to know the
>significance of various choices for numbers.
They make your life with LILO, the BIOS, DOS and other operating
systems easier; otherwise there's no difference. I think we put down
about 8K blocks in the equivalent of a BSD "cylinder group"; it really
doesn't make a difference on modern drives, and you'd be wrong anyways
since large drives don't have a constant density.
>I guess I don't need to worry about the "overlap" but I would be
>interested to know what it means. I am confused that the "begin"
>seems to have moved from what it was originally (but I'm not sure).
No idea.
>Should I be concerned by the 51 unallocated sectors?
>Is there another way to partition the disk to avoid it?
51 * .5K / the total ammount. Don't worry about it.
>Once I've fed the geometry info to lilo, will it be able to boot
>from anywhere on disk
No.
>(if I made it into one big partition say)
>or does this `1G BIOS limit', or whatever it is, still apply?
Yes. That's host adapter dependant; the SCSI-CAM annex A method used
by the NCR boards can be compatable with any existing partition table,
or will let you go up to 8G.
>On the system I have an IDE drive, a SCSI disk (id 0) and the
>micropolis (id 1). The current setup has / and swap (and a dos
>partition) on the IDE and /usr and /home on the SCSI disk. I am
>hoping to move all the linux stuff to the micropolis so that I can
>remove the IDE and smaller SCSI disk to another machine should that
>become desirable.
>
>Is there a way for me to boot off the micropolis without (as my
>reading implies I must) detaching the IDE drive?
No. However, there is nothing which precludes you from installing
LILO on the IDE drive, and booting kernels and mounting root from
the first SCSI drive; or booting kernels from the first SCSI drive
and mounting root on the second.
>The idea is to have all the `controls' (ie. lilo) on the micropolis
>so that the other drives can be removed if/when I feel like it,
>without having to fiddle with the setup.
You'll have to fiddle with the setup, but it's painless if you know
what you're doing.
