increasing dd disk to disk transfer rate
lists at jnielsen.net
Fri Jan 13 06:40:09 PST 2006
On Friday 13 January 2006 08:29 am, Christoph P. Kukulies wrote:
> 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.)
> 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.
> 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
> 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)
I don't know if this is why the system froze, but /dev/zero is probably not a
useful output device. You could use of=/dev/null just to see if the disk
reads succeed w/o errors. I've also done "cmp /dev/adX /dev/zero" before,
but you don't have any control over how the disk reads are handled that way.
More information about the freebsd-hackers