Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!botter!star!ast
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: bad blocks on hard disk
Message-ID: <495@ast.cs.vu.nl>
Date: Tue, 8-Sep-87 08:35:38 EDT
Article-I.D.: ast.495
Posted: Tue Sep  8 08:35:38 1987
Date-Received: Wed, 9-Sep-87 03:19:42 EDT
References: <196@turbo.RAY.COM> <489@ast.cs.vu.nl> <1135@laidbak.UUCP>
Reply-To: ast@cs.vu.nl ()
Organization: VU Informatica, Amsterdam
Lines: 35

In article <1135@laidbak.UUCP> guardian@laidbak.UUCP (Harry Skelton(E)) writes:
>?How bout a badtrack program and a mod to minix to have a bad_sector flag?
>/dev/hd (you can tell I don't play with minix) can be a list of sectors
>that are good and skipping the bad 'blocks' as needed or setup with
>'badtrack'  ??? Ideas ???


Does anyone know if the part program (nee format) that comes with MS-DOS
puts some kind of mark on bad sectors (e.g. bad checksum) to force them
to be bad all the time?

If one could guarantee that all bad sectors always gave errors, 100%
of the time, bad block handling would be straightforward.  

1. The driver just reads and writes normally.

2. If a repeated error occurs, the driver looks up an alternate sector
   in a table.  

This scheme requires 0 overhead in the normal case, but it does require
that bad sectors ALWAYS give an error.  If a bad sectors sometimes is
ok, this scheme fails.

Putting bad blocks in a "bad blocks file" is ok, except if the bad
block is the super block, inode block, etc.

Does anyone feels inspired to write a program that you call with
   badblock /dev/hd1 4813 9234
with the result that a file is created on /dev/hd1 with name 4813 and
whose only blocks are 4813 and 9234 (up to a maximum of 7)?  After 
jamming block numbers into the inode, either the program has to update
the bit map, or tell the user to run fsck.  (A version that runs on
MINIX was posted a month or two ago).

Andy Tanenbaum