Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdcad!philip
From: philip@amdcad.AMD.COM (Philip Freidin)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Norton Speed Disk Bug and Fix?
Keywords: Speed Disk Bug
Message-ID: <20291@amdcad.AMD.COM>
Date: 8 Feb 88 17:44:54 GMT
References: <327@ttrdf.UUCP> <2023@bsu-cs.UUCP> <990@neoucom.UUCP>
Reply-To: philip@amdcad.UUCP (Philip Freidin)
Organization: Advanced Micro Devices
Lines: 65

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)