Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!portal!cup.portal.com!thad From: thad@cup.portal.com (Thad P Floryan) Newsgroups: comp.sys.amiga Subject: Re: Seagate. Message-ID: <20314@cup.portal.com> Date: 11 Jul 89 05:29:09 GMT References: <8907020047.AA15716@lilac.berkeley.edu> <3671@ddsw1.MCS.COM> <10403@polya.Stanford.EDU> <3687@ddsw1.MCS.COM> <20260@cup.portal.com> <7682@cs.Buffalo.EDU> Organization: The Portal System (TM) Lines: 78 Joseph M. Piazza asks: " In an ealier posting you mentioned this occuring after three months -- almost to the day the problem showed on my 138N. Could you clarify? " (The above in reference to the elapsed period before one's Seagate drive starts getting finicky about spinning its main spindle). *MY* experience with the Seagate drives has been for > 12 months to elapse before the stiction problem revealed itself. Others encounter it earlier. This could be a function of whether one's drive had 2, 3, 4 or 5 wipes! :-) I also tend to keep my drives powered up for year(s) at a time between shutdowns because I operate all my computers on UPS systems; someone who powers ON/OFF daily is more likely to experience the problem earlier. As I stated in email response to someone else this weekend, the heads on the drive are acting like windshield wipers on a car's windshield, squeegeeing the material off to the sides. Material pushed towards the center of the platter is the material that causes trouble when the heads are PARKed, per: >6) after the drive is in use for awhile, the excess is pushed to the > INSIDE and the OUTSIDE of the platter. Anything beyond cylinder 0 is no > problem because the heads won't go there; BUT, the crap that was pushed > inwards (beyond, say, cylinder 820 in an ST251) is NOW is the area where > the heads are parked. When you shut your drive down, the heads now are > sloshing in that and the meniscus essentially GLUES the heads in > place, preventing the stepper from moving them from PARK when power is > re-applied. Joseph continues: " Wow, this is truely amazing. I thought I was mixed-up with respect to how many cylinders are avaible on the 138N. When I first got my drive it formated correctly to 615. A month or so later it would only format it to 605 (the number I currently have in my Montlist). At the time I figured it must have been a lapse of my memory. Now, ... " The funny thing about embedded SCSI drives is that one is NOT supposed to know or care HOW many heads or cylinders physically are in the drive. The operative word is simply "sectors". From the ST138N manual (yeah, "Know thy enemy"! :-) : When ones asks for 512-byte sectors (contrasted with 1024 or 256), the ST138N is guaranteed to have 62,933 sectors. Period. This is the ONLY datum one needs to operate this drive on a SCSI bus. You ask for sector 0, it gives it to you. You ask for sector 62,932, it gives it to you. You ask for sector 62,933 and you'll probably get beans. SCSI data organization, as far as the host is concerned, is simply block-relative. If you want to consider the physical organization of the ST138N, you will find that it has 155 sectors per cylinder (huh? yeah, that's what the manual says in several places), 26 sectors per track, and 1 diagnostic R/W cylinder. The functional specs claim: 2,452 tracks, 615 cylinders (0-614), 4 heads, 2 disks, and "2,7 RLL" recording. Joe says that formatting his ST138N with "605 cylinders" is what he did to make it work properly now. TRUE. If one has brain-damaged SCSI driver software that asks for heads and cylinders and other stuff that it's NOT supposed to know about, we can look again at the geometry of the ST138N and figure this all out per: The ST138N guarantees ONLY 62,933 sectors when using 512-byte sectors. Since we KNOW the physical layout to be 4 heads and 26 sectors per track, we can do a "back-of-the-envelope" calculation and discover: 1) 4 * 26 = 104 sectors per cylinder, physical 2) 62933/104 = 605.125 "cylinders" available for data The other "cylinders" (actually, sectors) are used by the drive as alternates for any earlier bad sectors found during the ST138N's low-level formatting. Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]