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