> 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 3751Received 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