Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I set up dd to clone a smaller system 40.00GB hard drive (/dev/sda) to a new bigger 111.00GB one connected via a USB reader (dev/sdb) and Its been going for two hours now. The activity meter on the new hard drive shows it's doing something. But the CPU is only about 20%. When is this thing going to complete? Should I re-start the process?

share|improve this question
up vote 35 down vote accepted

In the future, you should use pv to get a running progress bar.

sudo apt-get install pv

With pv installed, let's assume you want to clone a 20GB drive, /dev/foo, to another drive (20GB or larger!), /dev/baz:

sudo dd if=/dev/foo bs=4M | pv -s 20G | sudo dd of=/dev/baz bs=4M

Important bits to notice: the bs=4M argument sets the blocksize for dd operations to 4MB, which drastically improves the speed of the whole thing. And the -s 20G argument tells pv how big this operation is expected to be, so it can give you an ETA as well as a current speed.

I love pv so hard it should probably be illegal.

share|improve this answer
If course, pv is very useful, but if you are copying a lot of data it adds more context switches and buffer copies so it will consume more CPU and perhaps may slow things down a small amount. But since copying data is rate limited on the drives it won't add much overhead. – Colin Ian King Nov 23 '12 at 22:32
In actual practice, you are VANISHINGLY unlikely to see pv add so much as 0.1% to the time-to-copy. If you do, it's almost certainly an operation so blindingly fast that there was no point in trying to add a progress bar in the first place. – Jim Salter Nov 23 '12 at 22:34
Very true. I'm just and old style engineer who is just used to saving every cycle I can. – Colin Ian King Nov 24 '12 at 14:43
@ColinIanKing - I actually just discovered today that while pv itself doesn't slow things down any, piping to STDOUT and STDIN can. For normal dd operations from one conventional hard drive to another, it won't have any impact... but if you have a VERY high performance SSD, it will. My new Intel 520 480GB SSD is capable of 340MB/sec contiguous reads or so, but if I pipe like dd if=/dev/sda bs=4M | dd of=/dev/null bs=4M it only does 276MB/sec or so. Sadface. (The effect is even nastier for cached reads, which may go as fast as 16GB/sec if not piped.) – Jim Salter Nov 26 '12 at 4:55
revisiting this later yet: after some conversation with the author of pv, I discovered that you can avoid the speed penalty by taking dd out of the equation entirely: pv < /dev/sda > /dev/sdb works just fine, and will go every bit as fast as the underlying hardware is capable of going. – Jim Salter Aug 10 '13 at 16:54

You can see how far it has got by sending it a SIGUSR1 signal in order to see how much data it has copied and the transfer rate:

kill -SIGUSR1 $(pidof dd)

For copying activity you are limited by I/O speed of the device, so the CPU should not be fully loaded, so don't worry about that.

share|improve this answer
Noted. Well, I killed the process to figure out it was going quite slowly.. had to redo the partition table but it's back to all empty now. You know of any better ways to clone a hard drive the won't take all day? – seanthewebber Nov 22 '12 at 18:28
@SeanWebber: running that command should not actually terminate the dd process. From man dd: "Sending a USR1 signal to a running dd process makes it print I/O statistics to standard error and then resume copying." To speed up the process try specifying a larger block size as Jim Salter suggests in the other answer. – Sergey Nov 23 '12 at 0:31
OS X's dd must be broken since sending the SIGUSR1 killed it for me as well. – Jarrod Davis Feb 8 '14 at 20:59
From elsewhere: kill -INFO $(pgrep ^dd$) on BSD systems (like OSX). – ssnobody Jan 11 at 22:57

I've used pv as well as (ps and kill) in the past as suggested in the other answers, but more recently I've just been using dc3dd instead which produces the same results while providing a progress report throughout the process.

You can check to see if it's already installed with: which dc3dd

If not you can install it with sudo apt-get install dc3dd

The command switches are similar to dd (for cloning, although wiping is a bit more straightforward).

In your case I would use the command dc3dd if=/dev/sda of=/dev/sdb

share|improve this answer

I had a similar problem. The cause was different in my case.

The target drive is an external hard disk.

If the disk was mounted automatically via udisks and udisks-glue then the transfer rate from cdrom to the hd was about 40kB/s.

When I unmounted the hd and mounted it directly via mount I got a transfer rate of about 2.4MB/s.

share|improve this answer
Please add more info to this answer like how to mount it using mount and not udisks. – Parto Aug 23 '14 at 9:10

You could instead use ddrescue:

sudo ddrescue -v /dev/sda /dev/sdb

v stands for verbose.

share|improve this answer

same problem I just using a simple solution:

watch ls -l -h /path/to/file

it can't tell you when dd will done, but at least you know how many data copied.

share|improve this answer
-1 The question is about copying data from one block device to another. ls is of no help there. – David Foerster Mar 26 '15 at 9:15
@ElderGeek It is an attempt to answer the question, that comment is really no help hear. Thanks. – Seth Mar 26 '15 at 18:30
@ElderGeek Comments are only auto generated by the system in the Low Quality Posts queue. If someone has already posted a comment that addresses the issue with the post no comment needed would be the appropriate choice :) – Seth Mar 26 '15 at 18:44
You'll get the hang of it @ElderGeek :) – Seth Mar 26 '15 at 19:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.