Path: utzoo!utgpu!watserv1!watdragon!tiger!mwandel
From: mwandel@tiger.waterloo.edu (Markus Wandel)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Sloppy read/write error handling
Keywords: It doesn't work right
Message-ID: <22982@watdragon.waterloo.edu>
Date: 7 Apr 90 15:33:16 GMT
References: <556@bilver.UUCP> <15840@estelle.udel.EDU> <10595@cbmvax.commodore.com> <15878@estelle.udel.EDU> <10624@cbmvax.commodore.com> <5530@sugar.hackercorp.com>
Sender: daemon@watdragon.waterloo.edu
Organization: University of Waterloo
Lines: 60

In article <5530@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:

> ... As you pointed out, taking a multi-11K hit for spare tracks is a bit
> much....

Why does everybody keep talking about multi-11K hits?  You only have to take
out a track (5.5K) for a bad block, not the whole cylinder.  And I would say
that losing disk space in increments of 0.7% (that's how much of the total
capacity one track is) is not bad.  Of course, the bad block mapping would
have to be built into the file system, since the device driver could not
"pretend" it always has a flawless 880K disk, because there are no spare tracks.

I just can't understand what is so evil about doing bad block mapping at the
file system level.  Yes, MS-DOS does it, and does it well.  All we need on
the Amiga is a special "file", linked in to the root block for example, which
stores the addresses of all the bad blocks.  Disk optimizers could skip these,
and the validator could allocate them in the bitmap right off.  No problem.
Better yet, the format program could automatically link in any blocks that
it is unable to verify correctly in the format phase.  No problem.  And since
the format program is the only thing that creates the list, it is the only
place where special code would have to account for the trackdisk.device's
unusual behaviour.

Assuming an unused longword could be found in the rootblock, this scheme
could even be implemented transparently to old file systems.  They would just
validate the disks incorrectly, with no worse results than we now have.

Now for the benefits:

1. Damaged floppies can be used with only a small reduction in capacity (yes,
   5.5K at a time but so what).

2. PD programs would appear very quickly which can map out bad blocks on the
   fly, without reformatting a disk.

3. Device driver writers for things other than SCSI would not have to to worry
   about some nightmare algorithm which allows multiblock read/write commands
   while still skipping bad blocks (and it is a nightmare algorithm, I've
   thought about doing it for my 80MB SCSI disk on which bad block mapping is
   broken).

4. Users wouldn't be stuck with whatever half-baked schemes SCSI interface
   implementers have come up with to allow access to the underlying bad block
   management.  In particular, a lot seem to allow bad block mapping only at
   low-level format time, something which SCSI drives do not demand and the
   above-described scheme does not either.

5. The scheme described could be used to arbitrarily reserve areas of the disk
   to be immune from use by the file system or a disk optimizer, and immune
   to being deallocated by the disk validator.  Finally, we would have a legal
   way to store copy protection tracks, absolute code, long boot-sector code,
   and other oddities on a floppy disk legally.

6. Use of the scheme described would be entirely optional; no penalty whatsoever
   would be incurred if the disk is in fact flawless, and bad-block mapping at
   the device driver level could still be done if desired.

Markus Wandel
mwandel@tiger.waterloo.edu
(519) 884-9547