From owner-freebsd-questions@FreeBSD.ORG Tue Jul 6 10:44:24 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94796106566C for ; Tue, 6 Jul 2010 10:44:24 +0000 (UTC) (envelope-from kuku@kukulies.org) Received: from werkwelt.de (post.werkwelt.de [91.194.85.74]) by mx1.freebsd.org (Postfix) with ESMTP id 09E378FC08 for ; Tue, 6 Jul 2010 10:44:23 +0000 (UTC) Received: from [134.61.4.247] (account kuku@kukulies.org [134.61.4.247] verified) by werkwelt.de (CommuniGate Pro SMTP 5.0.13) with ESMTPSA id 6977105 for freebsd-questions@freebsd.org; Tue, 06 Jul 2010 12:43:49 +0200 Message-ID: <4C3308D2.6000704@kukulies.org> Date: Tue, 06 Jul 2010 12:43:30 +0200 From: Christoph Kukulies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <4B434D52.3030301@kukulies.org> <20100106023007.b3a19517.freebsd@edvax.de> <4C31E793.3040000@kukulies.org> <20100705213953.b56c3e01.freebsd@edvax.de> In-Reply-To: <20100705213953.b56c3e01.freebsd@edvax.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: copying a disk with ignoring errors X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 10:44:24 -0000 Am 05.07.2010 21:39, schrieb Polytropon: > On Mon, 05 Jul 2010 16:09:23 +0200, Christoph Kukulies wrote: > > >> I tried PHKs' recoverdisk with recoverdisk -b 1024000 /dev/ad2 ad2.dmp >> >> and it went off quite promising just few dma read timeouts and when I >> was at 7% of recovery >> it suddenly says: >> ad2: FAILURE - device detached. >> 1558528000 1024000 failed (device not configured) >> # >> > Not good. Can you obtain an 1:1 copy of the disk using ddrescue? > And it's often easier to operate partition-wise, if there are > functionally separated partitions on the disk; let's assume > the /home directory was mounted from slice 1 partition f, then > try: > > # ddrescue -d -r 3 -n /dev/ad2s1f home.ddr logfile > > If you are lucky to get a copy of this partition, you can try > to apply analytic and repairing tools to that partition copy. > > > > >> Hmm. How can I avoid that the device gets detached? >> > I do not think you can do anything against it. A device detachment > means a MASSIVE failure. It *can* be a problem of the controller, > but mostly it is a problem of the disk itself. There can be a way > to get around it - by replacing the disk's PCB with an identical > one. But it's not for sure that this will work, e. g. if the disk's > drive components have massive defects. > > A device detachment at least doesn't look like an "easy" I/O problem > within the drive's components (the platters, heads, the motors). > > The error must be that massive that the disk itself says goodbye > to the system and disappears so that no control commands will reach > it. > > You can try "atacontrol reinit" to force the disk back on-line, > but it may refuse to do so. See "man atacontrol" for other options. > You can also use the "smartctl" program (from port "smartmontools") > to check the drive's error memory to see what has caused the detachment; > maybe there's some information there. > > It's like /dev/cpu: device disappeared. :-) > Thanks for the detailed alternatives and explanations. I managed in a second attempt by using the option recoverdisk -b 102400 -r workfile -w workfile /dev/ad2 ad2.dmp (maybe I was using a different large number for the -b option, maybe I even tried it once with -b 0). Anyway the second time it held until I was down to a few thousand block being unrecoverable. In the end I was able to recover the data. Thanks. Christoph