Path: utzoo!attcan!uunet!nuchat!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga
Subject: Re: A plea for bad block handling in the file system.
Message-ID: <2116@sugar.UUCP>
Date: 13 Jun 88 19:38:51 GMT
References: <2009@sugar.UUCP> <7144@swan.ulowell.edu> <2026@sugar.UUCP> <6180@well.UUCP>
Organization: Sugar Land UNIX - Houston, TX
Lines: 51

In article <6180@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
> 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.

> 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.

You're not married, are you?

I've had expensive floppies and cheap floppies go bad on me. Floppies go
bad. Particularly in an environment that contains a two-year-old child,
a cat, and a smoker. I can't do anything about that. Despite what some
people may think, my computer *isn't* more important than my family.

ANYWAY, the point still remains that the Amiga's handling of errors is
a complete disgrace. I can't really push it as hard as I can without a
reliable disk drive *out of the box*. Other computers can operate in the
face of imperfect media.

> >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.

Leo, do you really think I'm that dense?

When I say "block" I'm talking about the basic unit of I/O. Not
an imaginary sector that only exists in the minds of the Commodore
programmers. The trackdisk.device "disk block" is 5.5K long and fills
a track.

> 	The only way to get around this is to have the trackdisk.device
> perform bad *track* mapping.

Or have the file system recognise that it's not dealing with perfect media.
Here's a case where the FS can definitely do something that the driver
can't: mark that track as read-only and use it as a copy-on-write cache.
There are *lots* of such optimisations that the FS can do.

Or blow off compatibility altogether and go to a sane file system like
UNIX's. With inodes, fast directory searches, and so on. When you wish
upon a star...
-- 
-- Peter da Silva      `-_-'      ...!hoptoad!academ!uhnix1!sugar!peter
-- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter
-- Disclaimer: These may be the official opinions of Hackercorp.