rdj@ttrdf.UUCP (Robert D. Jackson) (02/01/88)
I remember a month or so back that there was a discussion about a problem with the Norton Utilities 4.0 Speed Disk Program (SD) that would cause a hard disk to be trashed. Someone had said that they had talked to Norton and they were going to send them a fix for this bug. A friend of mine called them the other day referencing this problem, and they claim to know nothing about any kind of bug in Speed Disk. If someone who knows more about this would either post a reply or drop me some email, I would appreciate it. Thanks in advance. -- Bob Jackson (rdj@ttrdf) 312-982-3578 AT&T Information Systems Computer Systems Division, 5555 Touhy Ave., Skokie, IL 60077 PATH: ...!ihnp4!ttrdf!rdj
pervect@bsu-cs.UUCP (Barrett M. Kreiner) (02/03/88)
In article <327@ttrdf.UUCP>, rdj@ttrdf.UUCP (Robert D. Jackson) writes: > > I remember a month or so back that there was a discussion about a problem > with the Norton Utilities 4.0 Speed Disk Program (SD) that would cause > a hard disk to be trashed. Someone had said that they had talked to > Norton and they were going to send them a fix for this bug. A friend > of mine called them the other day referencing this problem, and they > claim to know nothing about any kind of bug in Speed Disk. Hmm.. this is interesting.. since I just shipped off my hard disk controller for having major problems while doing a Norton Speed disk.. I'm running an ADS PC-XT compatable with a Segate225 20meg hard disk. During my weekly Speed disk, I got to major media error (VERY surprising, since I have a flawless disk (I lucked out)). After a few minutes, the machine just DIED. I opened it up, took it apart, and put it back together. everything worked, except that it could not find or recognize my c: drive. I borrowed a controller from work, and managed to get my information off of the disk, but even with the other controller, I Still got the media errors. I know all that stuff about no software can harm hardware had been proven false, so could Speed Disk have damaged my controller? |---------------------------------------------------------------------------| |Barrett Kreiner UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!pervect | | Asstistant software tech, |-----------------------------------------------| | Ball State U. Muncie, IN | "I'll tell ya kid, the main problem with | |---------------------------| Pervish food is keeping the goo from crawling | | out of the bowl while you're eating it"| TOON: THE game for modern times | | CGA: Cute Greenback Accumulator EGA: ENHANCED Greenback Accumulator | | Disclamer: "I don't know them! I'm a student, nobody listens to ME!" | |---------------------------------------------------------------------------|
wtm@neoucom.UUCP (Bill Mayhew) (02/07/88)
I have read several times and have seen discussed on this network, a phenomenon referred to as sector creep. Apparently, sector creep is a cumulative phenomenon that causes disk data errors after extended time has passed. In a nutshell, there are guard bands of sync data recorded between data sectors on a disk. Due to physical limitations of the controller electronics and instantaneous rotational instability of the media, it is quite likely that part of the guard band will be overwritten by rewrites of the sector. Controller designers and O/S writers are aware of sector creep and normally design guard bands between sectors that assure many rewrites without danger of the secotrs running into each other. Over time, however, it is possible that the guard bands could be completely overwritten and sectors begin to overlap on a heavily used disk. Norton Utilities' speeddisk program could accelerate creep problems on an aging disk possibly since it is moving data around a lot to unfragment files. Recently I ran into what I suspect is a case of sector creep on an IBM XT computer that has been in service for about four years. One day, the file allocation table became unreadable on the XT's 10 meg drive. The software on the machine hadn't been changed for many months, and has not bothered other machines running the same software mix. Doing a low level format restored the drive to its original usability. Note that to get rid of sector creep, it is necessary to perform a low level format. For IBM ATs there is a program available on the advanced diagnostics disk. For HDU controllers from many companies that have on-board bios chips, you can use DOS' debug to call a low-level format routine from the BIOS ROM. Run debug, and type g=c800:005 at the prompt. Most formatting routines have a menu that makes the job pretty easy. You'll probably need to know the type number for your disk drive and if it requires write precompensation; that data can be obtained from the drive manufacturer. Unfortunately sellers of clone machines seldom give you sufficient information on the hard disk on your clone. When our lab people here buy clone machines, I ask them to have the clone seller provide information necessary to do the low level format. In most versions of [MS]DOS, a DOS level format only does a surface scan and zeroing of the FAT and root directory. Early versions of AT&T and Compaq are exceptions to the above. --Bill
philip@amdcad.AMD.COM (Philip Freidin) (02/09/88)
In article <990@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: > >I have read several times and have seen discussed on this network, >a phenomenon referred to as sector creep. Apparently, sector creep >is a cumulative phenomenon that causes disk data errors after >extended time has passed. > >In a nutshell, there are guard bands of sync data recorded between >data sectors on a disk. Due to physical limitations of the >controller electronics and instantaneous rotational instability of >the media, it is quite likely that part of the guard band will be >overwritten by rewrites of the sector. Controller designers and >O/S writers are aware of sector creep and normally design guard >bands between sectors that assure many rewrites without danger of >the secotrs running into each other. > >Over time, however, it is possible that the guard bands could be >completely overwritten and sectors begin to overlap on a heavily >used disk. Norton Utilities' speeddisk program could accelerate >creep problems on an aging disk possibly since it is moving data >around a lot to unfragment files. > >.....more deleted.... >--Bill As a 'controller designer' and 'O/S writer', I am sorry to tell you that this seems to be all rather unlikely. The controllers when setup to do a low level format, write a repeated pattern of: inter sector gap code (several bytes long) sync code (even more bytes long) end of sync code (1 bit, or maybe a byte) start of sector header header header crc/parity/ecc/whatever splice region data sync code (several bytes) data sync code end data data crc/parity/ecc/whatever trailer region intersector gap ....etc... when writing to the disk, sufficient of the pre header sync code must be valid for the PLL to sync onto. The header is read, the crc(/whatever) is checked, and if the right sector is found, the writing starts in the splice region. If the disk is turning too fast (a few percent) then the data could overwrite part of the intersector gap. If things were realy sick, you might even overwrite part of the pre header sync. If things were broke, and you overwrote any of the header, then you would be damaging the next sector, and may not be able to access it, due to never being able to read the header validly. This is an instantaneous error though!!! There is no way that the error could accumulate, as the writes ALWAYS start in the splice region. If sectors are fading away on you, the problem is much more serious than overuse!. Philip Freidin @ AMD SUNYVALE on {favorite path!amdcad!philip) Section Manager of Product Planning for Microprogrammable Processors (you know.... all that 2900 stuff...) "We Plan Products; not lunches" (a quote from a group that has been standing around for an hour trying to decide where to go for lunch)
dbraun@cadev4.intel.com (Doug Braun ~) (02/10/88)
In article <20291@amdcad.AMD.COM> philip@amdcad.UUCP (Philip Freidin) writes: >In article <990@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: >> >>I have read several times and have seen discussed on this network, >>a phenomenon referred to as sector creep. Apparently, sector creep >>is a cumulative phenomenon that causes disk data errors after >>extended time has passed. >> >There is no way >that the error could accumulate, as the writes ALWAYS start in the >splice region. > I looked at schematics for a (Shugart 10 meg) winchester, and I noticed something interesting. This drive, and most smaller, cheaper winchesters, use diodes to switch the heads. Each head is center-tapped, and a positive voltage is applied to the center tap to forward-bias diodes that run from the end-taps on the heads to the preamp inputs. The circuit looks like this: ________ --------------->|------+---| | ( | | | ||| ( other head ->|--' | | ||| ( | | head ||| (------- +V | preamp|------------ coil ||| ( | | ||| ( | | ( | | --------------->|------+---| | | | | other head ->|--' -------- The same switching voltage also provides the write current. The point is that to forward bias the diodes, there must be a dc current running through the heads at all times. This would produce some magnetic field. This field, possibly in conjunction with the earth's (rotating at 3600 rpm relative to the platters) could eventually start erasing the disks. Doug Braun Intel Corp CAD 408 496-5939 / decwrl \ | hplabs | -| oliveb |- !intelca!mipos3!cadev4!dbraun | amd | \ qantel /
keithe@tekgvs.TEK.COM (Keith Ericson) (02/16/88)
In article <1673@mipos3.intel.com> dbraun@cadev4.UUCP (Doug Braun ~) writes: > [deleted discussion and "schematic" diagram] >The point is that to forward bias the diodes, there must be a dc >current running through the heads at all times. This would produce >some magnetic field. This field, possibly in conjunction with the >earth's (rotating at 3600 rpm relative to the platters) could >eventually start erasing the disks. I'll bet dollars to donuts that the current goes thru the head such that the magnetic field from each "half-head" portion (see previous article for schematic) cancels out the other. keith