Path: utzoo!attcan!utgpu!watmath!att!rutgers!ucsd!ucbvax!hplabs!hp-sdd!ncr-sd!noel!greg
From: greg@noel.CTS.COM (J. Gregory Noel)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Problems with Formatting 1224 contiguous cylinders on a Maxtor Drive
Message-ID: <0445.AA0445@noel>
Date: 14 Nov 89 22:55:57 GMT
Lines: 39

Rick Flower (rickf@pnet02.gryphon.com) writes:
>Well, I just borrowed a large Maxtor drive from a friend and was in the
>process of formatting it and before it would finish, it would crash the entire
>system -- not to the GURU level though..

I had this same problem with a Maxtor "1224" cylinder disk I got via Newbury
Data.  I ended up having to call the factory about it.  It turns out that the
last two cylinders are reserved for use by the controller for spare tracks,
control information, and so forth, so that you can only use 1222 cylinders.

I also had some problems with making a FFS partition the only one on the disk
(WB 1.2; this may have been fixed); it kept turning into an OFS partition.  I
ended up lying about how the disk was laid out by claiming there were only
five heads per cylinder and made an OFS partition on the bottom two-thirds of
the first cylinder.  It worked for me; your mileage may vary.
>	Surfaces = 15		I used 5
>	LowCyl = 1		I used 3
>	HighCyl = 1223		I used 3665 (1221*3 + 2)
The OFS partition then runs from "cylinder" one to "cylinder" two.

Also, you might want to check the documentation very carefully about this one:
>	BlocksPerTrack = 32
My documentation gave the "blocks per track" and "accessible blocks per track"
differently -- there's one block per track reserved for bad-block recovery.  I
almost didn't find this out.....  (Unfortunatly, the disk and the documentation
are now about 1400 miles away, so I can't look to see whether there are 33 or
32 real blocks per track (32 or 31 available, respectively).)

One other thing:  Has anybody ever looked into a hddisk.device that does track-
level I/O, similar to the floppy drive?  My calculations say that if there were
such a thing, you could get over forty sectors per track, or about 25% more on
the disk.  This seems like such a significant improvment that I must be missing
something; I can't believe that I'm the only one that would have noticed this.
The only reason I can think of is that there are really so many bad sectors
normally smoothed out by the extra sector per track that would be bad tracks in
this scheme that they would swamp the bad-track overflow area.  Anybody know
for sure?
--
J. Gregory Noel, UNIX Guru         greg@noel.cts.com  or  greg@noel.uucp