From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 13 13:29:24 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BAB316A423; Fri, 13 Jan 2006 13:29:24 +0000 (GMT) (envelope-from kuku@www.kukulies.org) Received: from www.kukulies.org (www.kukulies.org [213.146.112.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D01C43D60; Fri, 13 Jan 2006 13:29:22 +0000 (GMT) (envelope-from kuku@www.kukulies.org) Received: from www.kukulies.org (localhost [127.0.0.1]) by www.kukulies.org (8.13.3/8.12.10) with ESMTP id k0DDTGAS006971; Fri, 13 Jan 2006 14:29:18 +0100 (CET) (envelope-from kuku@www.kukulies.org) Received: (from kuku@localhost) by www.kukulies.org (8.13.3/8.12.10/Submit) id k0DDTFq5006970; Fri, 13 Jan 2006 14:29:15 +0100 (CET) (envelope-from kuku) Date: Fri, 13 Jan 2006 14:29:15 +0100 From: "Christoph P. Kukulies" To: "Kenneth D. Merry" Message-ID: <20060113132915.GA6848@kukulies.org> References: <200601120948.k0C9mcqR092895@www.kukulies.org> <20060112211300.GB13244@cirb503493.alcatel.com.au> <20060112212337.GA80216@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060112212337.GA80216@nargothrond.kdm.org> User-Agent: Mutt/1.4.1i Cc: Peter Jeremy , freebsd-hackers@freebsd.org, Christoph Kukulies Subject: Re: increasing dd disk to disk transfer rate X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2006 13:29:24 -0000 On Thu, Jan 12, 2006 at 02:23:37PM -0700, Kenneth D. Merry wrote: > > written by phk) that is designed to do disk-to-disk recovery - it > > copys data in big slabs until it gets an error and then works around > > the faulty area block by block. > > It's called 'recoverdisk', and is in src/tools/tools/recoverdisk. > > I used it to copy a friend's hard drive, and it worked well. (Although the > supposedly 'bad' disk didn't turn out to have any bad sectors.) > > Ken I was able to recover. The 0.99999980 copy of my damaged disk to the identical new one, using recoverdisk /dev/ad2 /dev/ad3 turned out to have been successful. The program was still trying to improve the result but I didn't see any increase of recoverd block, so I terminated it. But the result was a fully functioning bootable (Windows XP) disk. Probably due to the fact that the system (Windows) had been successful in repairing itself by remapping bad clusters of files to intact areas (all partitions were FAT32) the resulting copy was fully functional. I never had really hard disk errors, just the frequent CHKDSK that were required. I believe to recall that Hitach (IBM) had a design error in their Deskstar series when the firmware of the drive did not randomly park the head but left it only at the beginning of the disk all the time resulting in that area preferably being 'worn out' - I have been victim of that bad 40 GB Deskstar series in the past several times. Don't know if this still was the case with the Travelstar mobile computers disks series. The frequent errors I had in hiberfil.sys point into something in that direction (only my little theory). Just for the record: Before I wanted to give back in my faulty disk to my computer supplier as a case for warranty, I zeroed out the faulty disk. dd if=/dev/zero of=/dev/ad2 bs=1m It took half an hour to zero out the 80GB. Transferrate 44 MB/s? And not a single error ? Or is this normal? Then I tried to read back dd if=/dev/ad2 of=/dev/zero bs=2m Yes, just for the fun I said 2m blocksiye. And now we come back to FreeBSD contents: The system froze at this command (FreeBSD 5.2.1 on that machine) -- Chris Christoph P. U. Kukulies kuku_at_kukulies.org