NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/unix/wizards/3785

Internet Message Format | 1992-09-03 | 3.0 KB

Path: sparky!uunet!olivea!decwrl!pa.dec.com!nntpd2.cxo.dec.com!nabeth!alan
From: [e-mail] (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Newsgroups: comp.unix.wizards
Subject: Re: Disk bad block
Message-ID: <[e-mail]>
Date: 3 Sep 92 23:06:16 GMT
References: <[e-mail]>
Sender: alan@nabeth (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Reply-To: [e-mail] (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Distribution: usa
Organization: Digital Equipment Corporation
Lines: 61


In article <[e-mail]>, [e-mail] (P S Narayan) writes:
>
>Hello,
>Could any one tell me how does the file manager in the Unix File System
>detect a bad block and keep a track of it so that it is never allocated
>to any file. What is badness in a block ?
>I imagine the bad block list  is kept in the zeroth block of the  filesystem.
>
As Dave Olson mentioned, it depends.

Some possible answers:

1.  Some UNIX systems will expect perfect media and not cope with
    bad blocks at all.  If you happen to have an underlying I/O
    that does cope well with them this might be alright.  Unless
    the subsystem expect help from the operating system.

2.  Others acknowledge that bad blocks occur, but know they have
    I/O subsystems that will take care of them.  They are willing
    to help the I/O subsystem perform this task.

3.  Other make no assumption that the subsystem is going to do
    anything interest and take care of themselves.  The methods
    probably vary from a "bad block file" that has the bad
    blocks allocated to it, to systems that hide real disk
    under a layer that maps out the bad blocks.  All you ever
    see is the perfect surface presented by this layer.

On the nature "badness" in a block.

To various degrees the disks you're using have error detection
(and correction) codes stored with the data on the disk.  When
it reads a block it compares runs the data through whatever
firmware or hardware that calculates the error detection code
to see if they match.  If not the block is consider bad.

If the disk or controller supports error correction it will
try to fix the error.  Way down in the operating system it may
present this state as "Data corrected, but it was X badly broken".
The host may then be responsible for telling the controller what
do with the block; replace it and write the still good data back
to the new block.  The controller may decide to do this itself.
and will just tell the host "here's a good copy.  I fixed it."

Sometimes it won't be able to correct the data and still reports
a bad block.  The controller may still go off and replace the bad
block, writting the bad data to a now good block.  Unfortunately
it may not have any way to differentiate between a bad block
and a good block with known corrupt data.  What the host does
in these cases depends on how paranoid they are about data
reliability.

>Regards
>Narayan
>[e-mail]
>Texas A&M University
>
>
--
Alan Rollow                [e-mail]