Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!usc!apple!oliveb!amiga!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Sloppy read/write error handling
Keywords: It doesn't work right
Message-ID: <10735@cbmvax.commodore.com>
Date: 10 Apr 90 00:44:25 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>
Reply-To: daveh@cbmvax (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 56

In article <5530@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
>In article <10624@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes:
>> As I pointed out, that's not ture.  And the bad end of it is that the
>> filesystem would have to have device-level knowledge of each and
>> every device to effect the bad-block mapping.

>No it wouldn't. All it needs to do is mark a bad block as "bad", take a
>new block off the free list, and use it instead. The *only* device this
>wouldn't work for is trackdisk.device... which would need some special
>voodoo. 

Can you be absolutely sure that trackdisk.device is the only device that'll
ever be a bit weird?  Just because it's the only non-block-oriented device
right now doesn't imply that it always will be.  

And how about devices that automatically handle bad block mapping below the 
FileSystem level?  In that case, you could very easily end up mapping any
bad block twice.

>Either that, or add the bloody track mapping to td.dev, let format pre-map
>bad tracks out, and give us a version of disksalv or diskdoctor that's
>worth a damn. The current situation is intolerable. 

Personally, I think the current DiskSalv is worth a damn.  Maybe two.  It
can't re-create data that just plain doesn't exist anymore on the floppy, but
if you ever find a file it can't recover, *PLEASE* send me a copy of that
disk.  I want disks that DiskSalv can't recover.  I mean, I can make my own
bad disks under 1.3 by repeatedly yanking and inserting, but some errors you
just can't re-create.

>I've given up trying to do development off floppies altogether... they're 
>just not reliable enough (and, yes, my drives have been cleaned, checked, 
>aligned, landered, starched, and pressed). 

Well, I used 'em for a few years and never had any serious problems.  Sure,
there were occasional problems, and I would be the last one to argue against
some form of block or track mapping on the floppies.  Even though I did work
off floppies for a long time, I wouldn't recommend them for professional
code development on any machine.

>But that's beside the point. It's really nice to have hardware that hides
>bad sectors. But that doesn't mean that drivers should do so as well. If
>you're going to have the 68000 mapping sectors around, why not do it at a
>level that knows what those sectors mean?

I think it's as important to do it at a level that knows where those 
sectors actually are.  The FileSystem only gets a logical picture of what's
on a device.  It can't possibly know where the blocks actually exit.
They could, for instance, be spread out over several disks. 

> _--_|\  Peter da Silva <peter@sugar.hackercorp.com>.

-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough