Path: utzoo!attcan!uunet!lll-winken!lll-tis!mordor!lll-lcc!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga
Subject: Re: A plea for bad block handling in the file system.
Message-ID: <6180@well.UUCP>
Date: 6 Jun 88 08:25:25 GMT
References: <2009@sugar.UUCP> <7144@swan.ulowell.edu> <2026@sugar.UUCP> <2762@umd5.umd.edu> <2070@sugar.UUCP>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: The CIA:  Third-World Governments Destabilized While-U-Wait.
Lines: 49

In article <2070@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>I'm not fortunate, then. I don't have a scuzzy drive. I have two 3.5"
>microfloppies. Their driver is trackdisk.device. It doesn't do it for me.
>The file system doesn't do it for me. What am I supposed to do? Buy three
>times as many disks and keep lots of backups. That's what.
>
	Or you could try hunting down reliable media.  I have almost never
had a problem with *my* drives (no consolation to you, I know).  I make a
point, whenever I can, of avoiding a disk that isn't made in Japan, that
isn't blue, and that is made by Verbatim.

	When buying a batch of floppies, open the door and look at a
reflection of a light source on the media surface.  It should be very shiny,
not dull, hazy, or "frosted" in any way, and should not have any regular
patterns on it (like parallel lines).  It should be perfectly smooth.  If a
dealer won't let you examine the media before purchasing it, point your nose
in the air and go elsewhere.

	And of course, only buy certified DS-DD media.

>Then how about putting it into the goddamn floppy drivers. OK, let's try
>this another way. Commodore: practice what you preach and put bad block
>handling in trackdisk.device. It's gotta be somewhere... the current situation
>is just not acceptable.
>
	Someone from Commodore explained sometime back (rather well, I
thought) that bad *block* handling cannot be integrated into the
trackdisk.device because of the way it reads and writes tracks.  It does not
observe the start-of-track marker.  When asked to perform a write, it merely
starts blasting bits onto the media.  It is up to the read routine to figure
out which sectors are which.

	The upshot of this is that, since a disk write can start anywhere,
sectors move around the physical track.  Hard errors are more or less
stationary.  Therefore, from write to write, an error will seem to move from
sector to sector.

	The only way to get around this is to have the trackdisk.device
perform bad *track* mapping.  However, that can become expensive in terms of
disk space.  I'm also not sure if it is feasable or whether the benefits
would outweigh the costs of putting the feature in (and thereby introducing
another level of incompatibility).

P.S:	I've put a new quote in my .signature for as long as I find it
	amusing.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape  ihnp4!pacbell -\
 \_ -_		Recumbent Bikes:	      dual ---> !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Hmm, you're right.  Air is made up of suspended meat loaf."  -- Josh Siegel