Possible Duplicate:
dd: How do I know if it's still working?

I'm using dd to clone a disk to an image file, and compress it on the fly:

dd if=/dev/sda | gzip > /mnt/image_file

How can I check how much data dd already processed?
Looking at the output file size is of course useless, due to it being compressed.


Most dd implementations print status information upon recieving SIGUSR1. pkill -USR1 -x dd is probably what you want.

  • b-e-a-utilful. The only thing I can add is: while true; do pkill -USR1 -x dd; sleep 1; done – Fidel Jan 3 '13 at 15:13
  • 3
    @Fidel If you truly want beautiful, you should let it end when dd isn't around any more: while pkill -USR1 -x dd; do sleep 1; done ;-) – Chris Down Jan 3 '13 at 15:15
  • Not all implementations of dd respond this way to SIGUSR1 (my Mac's implementation requires SIGINFO) so it's worth checking in the man page. – Samizdis Jul 9 '13 at 15:46
  • Be wary and test this on your system before using it - on FreeBSD sending SIGUSR1 to dd will terminate it (FreeBSD uses SIGINFO, so substitute "INFO" for "USR1"). – Chiara Coetzee Dec 8 '13 at 1:03

Try pv, the pipe viewer. I just tested and it works on /dev/sda directly, meaning you even get a deterministic progress bar.

Regarding the times:

I created a random file with dd if=/dev/urandom of=random bs=4k count=10000. I then tried several methods of reading it:

$ time dd if=random | gzip >rand.gz
800000+0 records in
800000+0 records out
409600000 bytes (410 MB) copied, 17.9261 s, 22.8 MB/s

real    0m17.940s
user    0m16.545s
sys     0m1.248s
$ time pv random | gzip >rand.gz
 391MB 0:00:17 [22.1MB/s] [==================================>] 100%            

real    0m18.048s
user    0m16.477s
sys     0m1.048s
$ time <random gzip >rand.gz

real    0m18.410s
user    0m16.401s
sys     0m0.596s

I ran it again, pv and dd were even closer and lower than <. I conclude that the performance of pv and dd are the same to within a very small margin of error.

  • Unfortunately, it's not available on the live CD I'm using to do the cloning (and besides, I'm halfway through and I'd rather not stop it only to change the command line). Nice to know, though. – Massimo Feb 29 '12 at 20:44
  • It will (marginally) slow down the transfer, however. – Chris Down Feb 29 '12 at 21:57
  • @ChrisDown Perhaps a small amount, I don't think it'll be the bottleneck. – Kevin Feb 29 '12 at 22:03
  • That would depend on the hardware in use. I could imagine it happening on an SSD with an old-ish machine. – Chris Down Feb 29 '12 at 22:18
  • @ChrisDown I was thinking of gzip as the bottleneck, which would almost certainly be the case on an older machine. – Kevin Feb 29 '12 at 22:29

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