Date: Wed, 20 Apr 2016 09:29:22 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Matthias Apitz <guru@unixarea.de> Cc: freebsd-questions@freebsd.org Subject: Re: tool for mapping away bad blocks on an external disk Message-ID: <alpine.BSF.2.20.1604200926500.79585@wonkity.com> In-Reply-To: <20160420144819.GA2481@c720-r292778-amd64> References: <20160417072641.GA2358@c720-r292778-amd64> <20160417093957.0b1acb4c37d7c15a4b06af88@sohara.org> <alpine.BSF.2.20.1604171023510.30232@wonkity.com> <nf0h0u$5ij$1@ger.gmane.org> <alpine.BSF.2.20.1604171136320.30232@wonkity.com> <20160418065534.GA2198@c720-r292778-amd64> <20160420144819.GA2481@c720-r292778-amd64>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 20 Apr 2016, Matthias Apitz wrote: > El día Monday, April 18, 2016 a las 08:55:34AM +0200, Matthias Apitz escribió: > >> >> Thanks for all the hints; I started last night with overwriting the full >> disk with: >> >> # dd conv=noerror if=/dev/zero of=/dev/da0 bs=1m >> >> ... > > The dd ended as. I issued from time to time a kill -INFO to the dd to > see its progress: > > # tail nohup.out > ... > 885016+0 records in > 885016+0 records out > 928006537216 bytes transferred in 35244.495687 secs (26330538 bytes/sec) > 980612+0 records in > 980612+0 records out > 1028246208512 bytes transferred in 39028.251450 secs (26346202 bytes/sec) > dd: /dev/da0: Input/output error > 1154078+0 records in > 1154077+0 records out > 1210137444352 bytes transferred in 45969.382123 secs (26324858 bytes/sec) > > Does this mean I could use the first 1154077 blocks of 1m as partition, > i.e. shrink it to this size and just ignore the rest? Maybe. Best to check the SMART data, then run a long test and see if the reallocated blocks have grown. Don't count on the SMART data saying the drive is good to be trustworthy. The manufacturers usually have it set so the drive is long past safe use by the time the SMART data actually admits it. From owner-freebsd-questions@freebsd.org Wed Apr 20 15:30:26 2016 Return-Path: <owner-freebsd-questions@freebsd.org> 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 EE915B16AE0 for <freebsd-questions@mailman.ysv.freebsd.org>; Wed, 20 Apr 2016 15:30:26 +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 B4FEE1B2A for <freebsd-questions@freebsd.org>; Wed, 20 Apr 2016 15:30:26 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from <freebsd-questions@m.gmane.org>) id 1asu51-0003Mj-1h for freebsd-questions@freebsd.org; Wed, 20 Apr 2016 17:30:15 +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 <freebsd-questions@freebsd.org>; Wed, 20 Apr 2016 17:30:15 +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 <freebsd-questions@freebsd.org>; Wed, 20 Apr 2016 17:30:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org From: Michael Powell <nightrecon@hotmail.com> Subject: Re: tool for mapping away bad blocks on an external disk Date: Wed, 20 Apr 2016 11:31:13 -0400 Lines: 53 Message-ID: <nf87a0$amu$1@ger.gmane.org> References: <20160417072641.GA2358@c720-r292778-amd64> <20160417093957.0b1acb4c37d7c15a4b06af88@sohara.org> <alpine.BSF.2.20.1604171023510.30232@wonkity.com> <nf0h0u$5ij$1@ger.gmane.org> <alpine.BSF.2.20.1604171136320.30232@wonkity.com> <20160418065534.GA2198@c720-r292778-amd64> <20160420144819.GA2481@c720-r292778-amd64> Reply-To: nightrecon@hotmail.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit 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 <freebsd-questions.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions/>; List-Post: <mailto:freebsd-questions@freebsd.org> List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 20 Apr 2016 15:30:27 -0000 Matthias Apitz wrote: > El día Monday, April 18, 2016 a las 08:55:34AM +0200, Matthias Apitz > escribió: > >> >> Thanks for all the hints; I started last night with overwriting the full >> disk with: >> >> # dd conv=noerror if=/dev/zero of=/dev/da0 bs=1m >> >> ... > > The dd ended as. I issued from time to time a kill -INFO to the dd to > see its progress: > > # tail nohup.out > ... > 885016+0 records in > 885016+0 records out > 928006537216 bytes transferred in 35244.495687 secs (26330538 bytes/sec) > 980612+0 records in > 980612+0 records out > 1028246208512 bytes transferred in 39028.251450 secs (26346202 bytes/sec) > dd: /dev/da0: Input/output error > 1154078+0 records in > 1154077+0 records out > 1210137444352 bytes transferred in 45969.382123 secs (26324858 bytes/sec) > > Does this mean I could use the first 1154077 blocks of 1m as partition, > i.e. shrink it to this size and just ignore the rest? > I have done that on occasion; I actually have the extra storage drive in my webdev box partitioned that way now. It had a bad spot which the mfr's utility corrected, then a few months later a few more, then a large number of them splatted out but they were all in about the same 400MB space in the middle of the drive. So I have a small partition in front (with a few hundred MB cushion on either side) and a larger partition behind it, with the bad space in between unpartitioned. Not a recommended way to go about things, but I get to use the drive until I buy a replacement. I've procrastinated on that as it has now been stable for almost a year like that. Generally when you start seeing dead sectors the remap zone is full and the first few sectors going bad begin to snowball into larger numbers fairly quickly. Failing magnetic media is nothing to waste time over as it is only going to cause data loss. But you can do this - I just don't really recommend it as it generally is a waste of time because once the media begins to fail it will continue to do so. ymmv -Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1604200926500.79585>