262 lines
10 KiB
HTML
262 lines
10 KiB
HTML
<!--startcut ======================================================= -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<html>
|
|
<head>
|
|
<META NAME="generator" CONTENT="lgazmail v1.2J.g">
|
|
<TITLE>The Answer Guy 42: One Bad Sector</TITLE>
|
|
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"
|
|
LINK="#3366FF" VLINK="#A000A0">
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<H4>"The Linux Gazette...<I>making Linux just a little more fun!</I>"</H4>
|
|
<P> <hr> <P>
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<center>
|
|
<H1><A NAME="answer">
|
|
<img src="../../gx/dennis/qbubble.gif" alt="(?)"
|
|
border="0" align="middle">
|
|
<font color="#B03060">The Answer Guy</font>
|
|
<img src="../../gx/dennis/bbubble.gif" alt="(!)"
|
|
border="0" align="middle">
|
|
</A></H1>
|
|
<BR>
|
|
<H4>By James T. Dennis,
|
|
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
|
|
LinuxCare,
|
|
<A HREF="http://www.linuxcare.com/">http://www.linuxcare.com/</A>
|
|
</H4>
|
|
</center>
|
|
|
|
<p><hr><p>
|
|
<!-- endcut ======================================================= -->
|
|
<!-- begin 10 -->
|
|
<H3 align="left"><img src="../../gx/dennis/qbubble.gif"
|
|
height="50" width="60" alt="(?) " border="0"
|
|
>One Bad Sector</H3>
|
|
<H4 ALIGN="center">
|
|
It Doesn't Ruin the Whole Disk</H4>
|
|
|
|
|
|
<p><strong>From John Gilbert on Tue, 04 May 1999
|
|
</strong></p>
|
|
<!-- ::
|
|
One Bad Sector
|
|
~~~~~~~~~~~~~~
|
|
It Doesn't Ruin the Whole Disk
|
|
:: -->
|
|
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
I cant believe that its not possible to re-use or dispose of a bad
|
|
sector on a hard drive!!!
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
Please tell me its possible to do something!
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
I only have one bad sector - but its really pissing me off!
|
|
Isn't there something I can do?
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
Awaiting your response,
|
|
<br>JB.
|
|
</STRONG></P>
|
|
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
Hmm. You can "dispose" of a bad sector by adding it to
|
|
the bad blocks list. The easiest way to do this is to
|
|
allow the <tt>mke2fs</tt> and <tt>e2fsck</tt> tools "check" the portions
|
|
of the disk that underlie a given filesystem by using the
|
|
<tt>-c</tt> options to each of them.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
Thus, when you first create an ext2 filesystem you should
|
|
always add the <tt>-c</tt> option so that it will (transparently)
|
|
call the '<tt>badblocks</tt>' command and account for those that are
|
|
detected. (The installation front ends to most Linux and
|
|
GNU suite distributions, such as
|
|
<A HREF="http://www.redhat.com/">Red Hat</A>,
|
|
<A HREF="http://www.caldera.com/">Caldera</A>, etc.
|
|
have a checkbox on their menu/dialogs to enable this).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
When you suspect that additional sectors have gone bad
|
|
you should run '<tt>e2fsck -c</tt>' to add any newly bad sectors
|
|
to the bad blocks list that is maintained as part of the
|
|
the filesystem's metadata.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
There are similar features for other filesystem types ---
|
|
although in some cases you'll have to build the badblocks
|
|
table to a file and run the filesytem formatting utility
|
|
separately (I won't go into details about feeding a
|
|
badblocks list to each of the alternative Linux filesystem
|
|
types as I don't know them off hand and they'd only be of
|
|
interest to a tiny percentage of LG reader --- much less
|
|
than 1% by my guess).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
If the sector that goes bad is sector number one on track
|
|
zero --- then you have a paperweight. That one sector is a
|
|
single point of failure (SPOF) in the whole PC drive
|
|
management architecture. This is a limitation of the
|
|
architecture that lies below the OS level as it is imposed
|
|
by the BIOS. Certainly someone could write a BIOS to
|
|
overcome the problem. It's also possible that your hard
|
|
drive has quite a bit of built in redundancy to prevent the
|
|
problem from ever being visible to the BIOS.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
Modern hard drives are sophisticated pieces of electronics.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
They have embedded microprocessors running programs that map
|
|
their own arrangements of data blocks into an abstraction
|
|
that's compatible with the BIOS representation of a hard
|
|
disk. A BIOS "thinks" of a hard disk as a flat three
|
|
dimensional array of head and tracks (cylinders) and
|
|
sectors. In reality modern drives are almost always more
|
|
complex and far less regular.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
Most modern drives store more sectors on their outer tracks
|
|
than they do on the inner ones. This is referred to as ZBR
|
|
(zone-bit recording).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
Most drives have "extra" sectors on each track --- and
|
|
they'll automatically map the "extras" in for any sector
|
|
that they detect as bad or "weak."
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
All hard drives have always implemented some error detection
|
|
into their electronics. All recent drives (the last decade
|
|
or so) have also implemented at least rudimentary ECC, error
|
|
correction coding. When a drive's electronics detect errors
|
|
they automatically try several re-reads to "get it right."
|
|
Many drives are programmed to move the successfully read
|
|
data into one of the "extras" on that track when this
|
|
occurs. Likewise if they detect "correctable" errors
|
|
through their ECC mechanisms. Some drives might even
|
|
migrate data to extra sectors on adjacent tracks or heads.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
So, you generally won't see bad sectors on a modern drive
|
|
until there are enough of them that all of the available
|
|
extras on a given track, cylinder, or within a given zone,
|
|
are all in use.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
Most drives have a "hidden" extra cylinder on which they
|
|
store some of the persistent data for these low level
|
|
mapping and remapping operations. This is the "diagnostics
|
|
cylinder." I think that they also have at least one sector
|
|
per track or cylinder devoted to maintaining the bad block
|
|
remappings for that track. (Some drives might implement
|
|
this as an additional surface --- so that one drive head
|
|
is devoted to all diagnostics).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
Most modern hard drives also have quite a bit of RAM on
|
|
them. A half meg is minimal, and two to four meg is common
|
|
on larger, high performance SCSI drives. I don't keep up on
|
|
these things so they may have drives with 8 or 16 Mb
|
|
onboard.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
I've often wondered if it wouldn't make more sense for drive
|
|
manufacturers to support a small (socketed?) bit of NVRAM to
|
|
store the MBR and the location of their diagnostics data
|
|
map. Of course it's possible that some of them ARE doing
|
|
this --- since I wouldn't know.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
Of course I'm just speculating here. I've never designed
|
|
hard drives and my discussions with hardware engineers from
|
|
Seagate, Quantum and other aquaintances in the field have
|
|
been far less detailed than my preceding speculations.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
The key point here is that these drives are not just simple
|
|
arrays of heads, sectors and tracks. I think I read a
|
|
message from Linus recently (on the kernel-list, in
|
|
reference to discussions about implementing "elevator-seeking"
|
|
and similar tricks in the low level disk drivers) that
|
|
basically said: 'anyone who treats a modern hard drive as
|
|
anything other than a linear list of storage blocks is a
|
|
fool.'
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
As for "re-using" a bad sector: you shouldn't have to worry
|
|
about that. If you drive hasn't already done it automatically
|
|
and transparently then your best strategy is to mark it as
|
|
bad and let the OS work AROUND that spot. Occasional
|
|
surface defects and wear and tear are to be expected in any
|
|
mechanical equipment --- and hard drives are fundamentally
|
|
mechanical.
|
|
</BLOCKQUOTE>
|
|
<!-- sig -->
|
|
|
|
<!-- end 10 -->
|
|
|
|
<!--startcut ======================================================= -->
|
|
<P> <hr> <P>
|
|
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
|
|
>Copyright ©</a> 1999, James T. Dennis
|
|
<BR>Published in <I>The Linux Gazette</I> Issue 42 June 1999</H5>
|
|
<H6 ALIGN="center">HTML transformation by
|
|
<A HREF="mailto:star@starshine.org">Heather Stern</a> of
|
|
Starshine Techinical Services,
|
|
<A HREF="http://www.starshine.org/">http://www.starshine.org/</A>
|
|
</H6>
|
|
<P> <hr> <P>
|
|
<!-- begin tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<TABLE WIDTH="97%"><TR VALIGN="center" ALIGN="center">
|
|
<TD ROWSPAN="4" COLSPAN="1" WIDTH="37%"><A
|
|
HREF="../lg_answer42.html"
|
|
><IMG SRC="../../gx/dennis/answernew.gif"
|
|
ALT="[ Answer Guy Index ]"></A></td>
|
|
<TD WIDTH="10%"><A HREF="1.html">1</A></TD>
|
|
<TD WIDTH="10%"><A HREF="2.html">2</A></TD>
|
|
<TD WIDTH="10%"><A HREF="3.html">3</A></TD>
|
|
<TD WIDTH="10%"><A HREF="4.html">4</A></TD>
|
|
<TD WIDTH="10%"><A HREF="5.html">5</A></TD>
|
|
<TD WIDTH="10%"><A HREF="6.html">6</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD><A HREF="7.html">7</A></TD>
|
|
<TD><A HREF="8.html">8</A></TD>
|
|
<TD><A HREF="9.html">9</A></TD>
|
|
<TD><A HREF="10.html">10</A></TD>
|
|
<TD><A HREF="11.html">11</A></TD>
|
|
<TD><A HREF="12.html">12</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD><A HREF="13.html">13</A></TD>
|
|
<TD><A HREF="14.html">14</A></TD>
|
|
<TD><A HREF="15.html">15</A></TD>
|
|
<TD><A HREF="16.html">16</A></TD>
|
|
<TD><A HREF="17.html">17</A></TD>
|
|
<TD><A HREF="18.html">18</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD><A HREF="19.html">19</A></TD>
|
|
<TD><A HREF="20.html">20</A></TD>
|
|
<TD><A HREF="21.html">21</A></TD>
|
|
<TD><A HREF="22.html">22</A></TD>
|
|
<TD><A HREF="23.html">23</A></TD>
|
|
<TD><A HREF="24.html">24</A></TD>
|
|
</TR></TABLE>
|
|
<!-- end tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<P> <hr> <P>
|
|
<!-- begin lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<A HREF="../../index.html"
|
|
><IMG SRC="../../gx/indexnew.gif" ALT="[ Table Of Contents ]"></A>
|
|
<A HREF="/index.html"
|
|
><IMG SRC="../../gx/homenew.gif" ALT="[ Front Page ]"></A>
|
|
<A HREF="../lg_bytes42.html"
|
|
><IMG SRC="../../gx/back2.gif" ALT="[ Previous Section ]"></A>
|
|
<A HREF="../lg_tips42.html"
|
|
><IMG SRC="../../gx/fwd.gif" ALT="[ Next Section ]"></A>
|
|
<!-- end lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
</BODY></HTML>
|
|
<!--endcut ========================================================= -->
|