Path: utzoo!mnetor!uunet!cbmvax!steveb
From: steveb@cbmvax.UUCP (Steve Beats)
Newsgroups: comp.sys.amiga
Subject: Re: Disk Errors. AmigaDOS file system.
Message-ID: <3085@cbmvax.UUCP>
Date: 5 Jan 88 15:34:48 GMT
References: <1338@sugar.UUCP> <37823@sun.uucp>
Reply-To: steveb@cbmvax.UUCP (Steve Beats)
Organization: Commodore Technology, West Chester, PA
Lines: 41

In article <37823@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
>
>.......... As a Request For Enhancement, I think it would be nice to add
>a 'bad block' bitmap. If a new mount command with user selectable file
>systems is created you could do it that way. ...........................

I know I'm going to get roasted for this one but here goes anyway.  I don't
believe that bad block mapping should be a function of the file system.  We
have hddisk.device that handles bad block mapping on ST506 devices and the
SCSI devices usually handle this themselves.  Putting BBM into a filesystem
that is going to work with both of these types of media AND with floppies
too (and any other kind of track/sector oriented device) is really piling on
the redundancy, right?

Quoting sugar!peter, "There should be a little back fence chatting" between
the file system and the device.  I whole-heartedly agree with this when it
comes to header and data organisation, put data on consecutive sectors, start
headers on track boundaries etc. etc.  However, should a bad block appear in
the middle of an existing file, I maintain that it is the devices job to map
the bad block to a new place.  This should be done in a manner that doesn't
mess up the data organisation maintained by the file system, ie. do the
back-fence-chatting both ways.  After all, a file system is supposed to be
a high-level interface to a low-level device/media.  It is perfectly
reasonable for the file system to assume it has ALL the sectors in the given
partition.

I think most of this discussion developed over the floppy file system.  Once
again, I maintain that bad block (actually track) mapping should have been a
function of trackdisk.device and not the file system.  I'm currently finishing
the FFS and I know for sure that retro-fitting bad block mapping would be a 
royal pain in the butt.  However, it isn't nescessary because all of the
devices it accesses handle the mapping themselves.

>.............................................. (Or get down and dirty and 
>replace the task pointer in the device nodes, handler task with one of your
>own.). 

I guess my answer to this is to replace the device node with your own :-)

>--Chuck McManis
	Steve