is 'dd' command taking too long?

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?

Asked By: user101351


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.

Answered By: Colin Ian King

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.

Note that while doing it this way is intuitive and nice and neat from left to right ordering, piping to and from STDOUT can incur a performance penalty if you’re talking about really fast data streams. The following syntax is faster, if you’re looking at moving several hundred MB/sec:

pv -s 20G < /dev/foo > /dev/baz

The -s 20G is optional, if you actually know how big (or about how big) the stream will be, it allows pv to give you a time estimate for completion. Without that, pv will try to figure out how large the dataset is if possible (for instance, it knows how big a file is) but if it can’t (eg with a block device, not a file), it just tells you the rate of transfer without guessing how long things will take.

Answered By: Jim Salter

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.

Answered By: Tobias

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


Recent versions of dd from the coreutils package version 8.24+ included in Ubuntu 16.04 and later include a status parameter. You can accomplish the same result with dd by adding the status=progress switch to your dd command line.

Example: dd if=/dev/zero of=/dev/null count=1000 status=progress

Answered By: Elder Geek

You could instead use ddrescue:

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

v stands for verbose.

Answered By: atmelino
Categories: Answers Tags: , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.