Path: utzoo!attcan!uunet!super!udel!rochester!rutgers!bellcore!tness7!tness1!sugar!peter
From: peter@sugar.uu.net (Peter da Silva)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Possibilities for speeding/expanding standard floppies
Message-ID: <2634@sugar.uu.net>
Date: 15 Sep 88 10:44:16 GMT
References: <2619@sugar.uu.net> <4733@cbmvax.UUCP>
Organization: Sugar Land Unix - Houston, TX
Lines: 47

In article <4733@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes:
> in article <2619@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) says:
> > In article <4705@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes:
> >> two.  This level of recover really doesn't belong in the trackdisk.device.

> > Weren't you just telling me that the device should present an error-free
> > disk to the file system? That was the rationale behind not putting error
> > correcting code there, remember. Where should this code be, then? The drive?

> I like the idea of the device handling the error checking/correcting as much
> as possible.  But it's not always possible in the context of a device driver.
  [ example of total catastrophic damage to a track ]

That's why I have been arguing for bad-block handling, at least to some degree,
in the file system. However, there are less catastrophic failure modes that
can be dealt with... for example, a write to a bad spot on the disk. On the
verification pass of the write, say, you get an error condition. What you have
to do here is write the track into a spare track and set some pointer that
indicates this track has moved.

Of course, the file system can do this better, since it's already got a bunch
of spare blocks floating around to put this stuff in... the device driver
would have to have allocated bad block tracks (as I understand SCSI disks
do). If the disk is full, of course, there's nothing you can do about it...
but at least some of the cases can be handled.

Anyway, after you do this you should still put up a requestor so the poor
dude can copy his data to a safer medium...

> Similarly, the File System doesn't know about the
> low level aspects of each individual device driver, so it's not qualified
> to solve the problem.  

True, but if the original data is still around the FS can blast all the
sectors back in new spots and update its pointers. One thing the td.device
can do is ask the FS for a safe place to put the data, and tell it where
the data was stuffed, but this is a bit extreme...

> The other solution is to tell the user he's got a bad disk, and let him
> go and get a utility specifically designed to recover bad disks.  That's what
> we do now.  I think's a decent way to solve the problem at hand.

Except for the occasions where you just guru and let the guy figure out his
disk is bad because it crashes whenever he puts it in...
-- 
		Peter da Silva  `-_-'  peter@sugar.uu.net
		 Have you hugged  U  your wolf today?