Path: utzoo!attcan!uunet!husc6!m2c!ulowell!page
From: page@swan.ulowell.edu (Bob Page)
Newsgroups: comp.sys.amiga
Subject: Re: A plea for bad block handling in the file system.
Message-ID: <7144@swan.ulowell.edu>
Date: 18 May 88 15:52:28 GMT
References: <2009@sugar.UUCP>
Reply-To: page@swan.ulowell.edu (Bob Page)
Organization: University of Lowell, Computer Science Dept.
Lines: 30

peter@sugar.UUCP (Peter da Silva) wrote:
>I'd just like to make another plea for bad block handling in the filesystem.

And I'll point out again that it's none of the FS' business what the
physical device looks like.  Let the driver present a perfect pack to
the file system.

>That's where it belongs: not duplicated dozens of times in dozens of drivers.

Sure, duplicated code in dozens of filesystems.  Not today, but
eventually.  Protocols in dealing with bad blocks between file systems
and drivers will expand, and soon everyone on USENET will be
discussing how to 'standardize' the protocols for filesystems talking
to drivers, and how bad blocks should be handled.

>but it's also better because the filesystem has more information
>about what that bad block *means*... FS should be able to move the
>block elsewhere.

So should the driver.  And the beauty is it doesn't care what the data is.

>In fact about the only write error that can't be recovered would be
>one in the root directory, and even then workarounds can be made.

Why work around it?  The driver doesn't care what the data is -
if the block is bad, revector it to another block.

..Bob
-- 
Bob Page, U of Lowell CS Dept.  page@swan.ulowell.edu  ulowell!page