[ltp] Bad hard drive sector

[Florian Reitmeir]

On Mon, 16 J=C3=A4n 2006, Theodore Ts'o wrote:

> On Mon, Jan 16, 2006 at 11:28:25AM +0100, Florian Reitmeir wrote:
> > On Son, 15 J??n 2006, Bill Sheppard wrote:
> > > So it looks like rewriting the sector cleared the error, at least for=
 now.
> > > Thanks everyone for the input...
> > Maybe you want to give "badblocks" a try, it can force sector relocatio=
n.
> Badblocks in read/write mode can force sector relocation; the sector
> only gets relocated on an attempted *write* to the sector.  Of course,
> as soon as you do that, the original data is lost forever, so in
> general most OS's will not automatically force bad block relocation
> when a read error is detected, in the hopes that the maybe the error
> is transient --- and the desire to allow the user to explicitly make
> the decision to abandon a certain piece of data.  Unfortunately, there
> doesn't seem to be a good way to get the list of blocks for which
> errors have been reported (other than manually grovelling through
> system logs).
>=20
> So the simplest and safest (if not the fastest) way of forcing the bad
> block relocation to take place is to run e2fsck -cc /dev/hdXXX with
> the filesystem unmounted.  =20

i use mostly XFS as filesystem, and xfs has no fsck tool. Only a repair too=
l.
and whats wrong with badblocks and the option '-o'? it returns the list of
really broken blocks, the other are all got relocated.

-o output_file
   Write  the  list  of  bad blocks to the specified file. Without this opt=
ion,
   badblocks displays the list on its standard output.  The format of this =
file
   is suitable  for  use  by  the  -l  option  in e2fsck(8) or mke2fs(8).

I my experience many new harddisks have a pair of badblocks, so running
badblocks before use is in many cases a real good idea. And no, some
bad blocks don't mean the HDD is breaking soon, its more like pixel errors =
in
TFT screens..

--=20
Florian Reitmeir