From owner-freebsd-questions@freebsd.org Sun Apr 17 17:27:10 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1703B10284 for ; Sun, 17 Apr 2016 17:27:10 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 663A4123C for ; Sun, 17 Apr 2016 17:27:09 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1arqTM-0002Wa-0z for freebsd-questions@freebsd.org; Sun, 17 Apr 2016 19:27:00 +0200 Received: from pool-72-66-1-32.washdc.fios.verizon.net ([72.66.1.32]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Apr 2016 19:27:00 +0200 Received: from nightrecon by pool-72-66-1-32.washdc.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Apr 2016 19:27:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org From: Michael Powell Subject: Re: tool for mapping away bad blocks on an external disk Date: Sun, 17 Apr 2016 13:28:03 -0400 Lines: 57 Message-ID: References: <20160417072641.GA2358@c720-r292778-amd64> <20160417093957.0b1acb4c37d7c15a4b06af88@sohara.org> Reply-To: nightrecon@hotmail.com Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pool-72-66-1-32.washdc.fios.verizon.net X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 17:27:10 -0000 Warren Block wrote: > On Sun, 17 Apr 2016, Steve O'Hara-Smith wrote: > >> On Sun, 17 Apr 2016 09:26:41 +0200 >> Matthias Apitz 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= >> 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