From: Rick Emerson (unixsys@ssg.com)
Date: 07/20/92


From: unixsys@ssg.com (Rick Emerson)
Subject: Re: FAQ addition: (was Re: Badblocks revisited (**sigh**))
Date: Mon, 20 Jul 1992 17:20:24 GMT

torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:

> In article <uR5ZNB6w165w@ssg.com> unixsys@ssg.com (Rick Emerson) writes:
> >u31b3hs@cip-s02.informatik.rwth-aachen.de (Michael Haardt) writes:
> >>
> >> Linux does not mark bad blocks, so you have to do that. It's not really
> >> difficult, it is just that you need MINIX to do the job. Don't yell at
> >> me ...
>
> [explanation of Minix and mkfs -c -l omitted]
>
> Also note that linux doesn't do bad-block mapping at a device level:
> It's done by the filesystem. Mapping bad blocks on a lower level is
> complicated, and often not worth it (as most new controllers do it in
> hardware).

Leaping to a conclusion - Linux marks, within .badblocks, places to be
avoided, right? This marking is the result of attempting to write and read
to a particular spot (without regard for any hardware bad block marking
system)? During a mkfs -c session I was bombarded with HD controller errors
and a slowly incrementing (from message to message) sector number. Can I
assume that having gone through all of this (the error messages), Linux
won't try to re-use this space? Can I bet my work on this?
 
> > You
> > must
> > be
> > joking!
>
> No, this was standard practice with the early versions of linux. I
> hadn't written a mkfs or a fsck, so you actually needed minix to set
> things up. Happily, this is no longer true, and hasn't been for about 8
> months or so.

Ah, well, then, in a sense, the recommendation to use Minix to map bad
blocks for Linux is a bad joke. <grin> What startled me about (possibly)
having to use Minix to map a Linux device was the idea of a nearly mature
version (0.9x vs. 0.1x) that was still unable to verify the validity of its
file structure without outside (i.e., Minix) help.
 
> >Install another OS to fix this one? (Yes, yes, yes, I know Linux is
> >descended from Minix)
>
> Actually, "descended" is too strong a word: I just used minix as the
> platform I wrote it on, and that has made its mark mostly on the
> original filesystem layout. Minix and linux are worlds apart
> internally: totally different principles in all things from interrupt
> handling to process control and memory management.

Point well taken, I should have said something to the effect that Linux'
*file system* is descended from Minix's. I rather assumed the context (file
system stuff) was enough to limit the scope of the inheritence in question.
I apologize for the ambiguity.

Again, my concern is avoiding the nightmare of seeing several hours' or
days' work vanish into a digital black hole because of an inability to avoid
defective spots in a volume.

What are the numbers that mkfs displays as it runs? I assumed they are bad
block numbers - maybe not?

Thanks for the historical background and my apologies for the ambiguity
about the file system's derivation.

Rick
 

+--------------------------------------------------------------------------+
| Richard B. Emerson | Replies may be sent to: |
| System Support Group | rick@ssg.com |
| Post Office Box 180 |-------------------------------------------------+
| Lansdale, PA 19446 USA | "Answers are the easy part |
| Voice: 215.855.1607 | questions raise the doubt." - Jimmy Buffett |
+--------------------------------------------------------------------------+