7

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.

Improve this question
1

2 Answers 2

Reset to default
10

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

Improve this answer
4
  • b-e-a-utilful. The only thing I can add is: while true; do pkill -USR1 -x dd; sleep 1; done Commented Jan 3, 2013 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 ;-) Commented Jan 3, 2013 at 15:15
  • 1
    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. Commented Jul 9, 2013 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"). Commented Dec 8, 2013 at 1:03
5

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.

Improve this answer
6
  • 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. Commented Feb 29, 2012 at 20:44
  • It will (marginally) slow down the transfer, however. Commented Feb 29, 2012 at 21:57
  • @ChrisDown Perhaps a small amount, I don't think it'll be the bottleneck. Commented Feb 29, 2012 at 22:03
  • That would depend on the hardware in use. I could imagine it happening on an SSD with an old-ish machine. Commented Feb 29, 2012 at 22:18
  • @ChrisDown I was thinking of gzip as the bottleneck, which would almost certainly be the case on an older machine. Commented Feb 29, 2012 at 22:29

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.