Date: Sun, 17 Apr 2016 13:28:03 -0400 From: Michael Powell <nightrecon@hotmail.com> To: freebsd-questions@freebsd.org Subject: Re: tool for mapping away bad blocks on an external disk Message-ID: <nf0h0u$5ij$1@ger.gmane.org> References: <20160417072641.GA2358@c720-r292778-amd64> <20160417093957.0b1acb4c37d7c15a4b06af88@sohara.org> <alpine.BSF.2.20.1604171023510.30232@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warren Block wrote: > On Sun, 17 Apr 2016, Steve O'Hara-Smith wrote: > >> On Sun, 17 Apr 2016 09:26:41 +0200 >> Matthias Apitz <guru@unixarea.de> wrote: >> >>> >>> Hello, >>> >>> I have an older external disk, connected through USB, which has bad >>> blocks: >> >> The tool you're looking for is badsect - I'm moderately surprised >> it's still around, the last time I used it was on FreeBSD 1.1.5.1 but it >> is still in FreeBSD 10.3. >> >> It doesn't do the analysis though - you'll have to do that with the >> filesystem unmounted and just used dd conv=noerror if=<device> >> of=/dev/null to read the whole device and pull the duff sectors out of >> the error messages. > > That won't remap them, though. > >> However it's been a *long* time since this was worth doing except >> perhaps as a last ditch data recovery exercise, drives have had internal >> sector remapping for a long time now and when that stops working they are >> well and truly banjaxed. > > True. But this is not (yet :) a data recovery problem, just a desire to > make the disk usable again. Bad blocks are only remapped on a write. > I think that a SMART long test (smartctl -tlong) writes every block > and will do remapping as a side effect, but have not verified it. > > The even more brute-force method would be to just manually write every > block on the disk with dd. A bs= of 64K or 128K or more will help speed > that up. Retries on bad writes might slow it down again. > > The drive could use up all available spares during that process, or > continue to grow new bad blocks. That makes the decision to scrap it > easy. If it successfully maps out the bad blocks and does not appear to > be creating new ones, then using it becomes a judgement call. As they > say, choose wisely. Back in the day (Fixed Direct Access SCSI-2 device) you could use the controller BIOS to do what used to be known as a "low level format" of SCSI drives in order to attempt to squeak a little more life from them. And if new bad spots did not begin to pop again right away you might be good to go for a while. If they did it indicated mass media failure that would just avalanche. The old Adaptec 1540 and 2940 controllers come to mind (Ctrl-A to enter the controller BIOS during POST). Can't do this through a USB subsystem. -Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?nf0h0u$5ij$1>