Re: Avoiding bad sectors?

From: Kevin Oberman <oberman_at_es.net>
Date: Sun, 20 Aug 2006 13:55:18 -0700
> Date: Sun, 20 Aug 2006 16:07:11 +0200
> From: "Daniel Eriksson" <daniel_k_eriksson_at_telia.com>
> Sender: owner-freebsd-current_at_freebsd.org
> 
> 
> First thing you should do is run a SMART selftest on the device using
> smartmontools:
> 
> smartctl -t long /dev/adX
> 
> Poll the status of the selftest using:
> 
> smartctl -a /dev/adX
> 
> until the selftest has finished (an hour or two) or aborted. This can be
> done while in multiuser mode, but beware that disc accesses will be
> slower than usual.
> 
> If you want to "fix" the problem and avoid downtime, then move swap to
> another slice (possibly an inode-backed md device, if that is possible)
> and fill the bad slice using 'dd'. Not sure if taking the data from
> /dev/random instead of /dev/zero makes any difference, but it will not
> hurt you other than by adding some time to the operation.
> 
> Once you've written to the bad slice you probably want to re-run the
> SMART selftest to make sure it passes without any more failures.

There have been some excellent suggestions in this thread, but one simple
detail looks like it's been over-looked.

If the disk has marked the sector as bad, which it should have, and it
there are redirection sectors available. a reboot is all that is
required. After reboot the entire swap space will be unused and the
first access to any sector will be a write. The sector will be remapped
on any write attempt, so as soon as that sector is used after boot, it
will be remapped to a spare sector and the error will be gone. No need
to force a write to that sector.

That said, using smartctl is an excellent suggestion. If it's just a
random block failure, it's no big deal and smart should tell you if the
problem is worse and it's time to go buy a new drive.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
Received on Sun Aug 20 2006 - 18:55:28 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:59 UTC