Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've not used dd all that much, but so far it's not failed me yet. Right now, I've had a dd going for over 12 hours - I'm writing an image back to the disk it came from - and I'm getting a little worried, as I was able to dd from the disk to the image in about 7 hours.

I'm running OSX 10.6.6 on a MacBook with a Core 2 Duo at 2.1ghz/core with 4gb RAM. I'm reading from a .dmg on a 7200rpm hard drive (the boot drive), and I'm writing to a 7200rpm drive connected over a SATA-to-USB connector. I left the blocksize at default, and the image is about 160gb.

EDIT: And, after 14 hours of pure stress, the dd worked perfectly after all. Next time, though, I'm going to run it through pv and track it with strace. Thanks to everyone for all your help.

share|improve this question
    
Not answering your question, but your times are quite high IMO. Did you remember to pass a bigger block size to dd other than the default 512 bytes? dd ... bs=16M is my suggestion, given your RAM, disk size and speed. –  Juliano Apr 13 '11 at 20:29
    
I didn't, simply because I wanted to play it safe. I'll try that next time, though. Thanks. –  kivetros Apr 14 '11 at 1:26
add comment

8 Answers

up vote 58 down vote accepted

You can send dd a certain signal using the kill command to make it output its current status. The signal is INFO on BSD systems (including OSX) and USR1 on Linux. In your case:

kill -INFO $PID

You can find the process id ($PID above) with the ps command; or see pgrep and pkill alternatives on mac os x for more convenient methods.

More simply, as AntoineG points out in his answer, you can type ctrl-t at the shell running dd to send it the INFO signal.

As an example on Linux, you could make all active dd processes output status like this:

pkill -USR1 -x dd

After outputting its status, dd will continue coping.

share|improve this answer
3  
Oh, very cool. You can combine those with pkill -USR1 -x dd –  Michael Mrozek Apr 13 '11 at 17:26
4  
@kivetros: On BSD systems, you need to send the INFO signal. Linux doesn't have a SIGINFO and uses USR1 instead. –  Gilles Apr 13 '11 at 18:50
2  
The SIGUSRx signals are for programs to do what they want with, as opposed to having a standardized meaning. SIGWINCH, for example, is raised when the terminal has changed its size and the program might need to redraw its screen. The operating system doesn't send SIGUSRx's so they are available for custom uses. –  ultrasawblade Apr 14 '11 at 1:17
5  
Sending dd the USR1 signal too soon after it has started (i.e. in a bash script, the line after you started it) will in fact terminate it. Put a 0.1 second sleep in between and it will output its progress properly. By the way, a very nice dd command to test USR1/INFO on is dd if=/dev/zero of=/dev/null. :) –  Lauritz V. Thaulow Apr 14 '11 at 8:51
5  
BTW, all "true" BSDs send SIGINFO to foreground process group if status character (Ctrl+T by default) is sent to terminal. But I don't know whether is it true for MacOSX. –  Netch Nov 1 '12 at 20:14
show 6 more comments

For dd, you can send a signal. For other commands that are reading or writing to a file, you can watch their position in the file with lsof.

lsof -o -p1234    # where 1234 is the process ID of the command
lsof -o /path/to/file

If you plan in advance, pipe the data through pv.

share|improve this answer
    
pv looks amazing - I'm definitely going to use that next time. Thank you so much. –  kivetros Apr 14 '11 at 1:27
1  
+1 - pv looks like just the ticket. –  boehj Jul 13 '11 at 7:00
add comment

Under OS X (didn't try on Linux), you can simply type Ctrl+T in the terminal running dd. It will print the same output as kill -INFO $PID, plus the CPU usage:

load: 1.40  cmd: dd 34536 uninterruptible 3.49u 64.58s
5020305+0 records in
5020304+0 records out
2570395648 bytes transferred in 4284.349974 secs (599950 bytes/sec)

I found out about it reading this thread, and trying to open a new tab in my terminal but mixing +T with Ctrl+T.

share|improve this answer
    
Wow. That's lucky! –  XAleXOwnZX Aug 21 '13 at 19:23
add comment

I usually attach strace to such a running process (with the -p $PID option) to see if it stays blocked in a system call or if it is still active.

Or, if you feel nervous about sending a signal to the running dd, start another dd to validate if this works.

share|improve this answer
1  
How exactly would you go about attaching strace? Also, I did start another dd and send one of the suggested signals to it, and... it killed it. –  kivetros Apr 14 '11 at 13:15
1  
If you know the pid of the running dd process, just do strace -p <pid>. You should see the log of all system calls called by the process (mostly read and write) –  philfr Apr 14 '11 at 14:07
    
That's beautiful. Thank you so much. –  kivetros Apr 14 '11 at 14:10
add comment

A more general way is to use iotop that displays the current amount of disk reading / writing per program.

share|improve this answer
add comment

ddrescue will give you stats as it's running.

demo: http://www.youtube.com/watch?v=vqq9A01geeA#t=144s

share|improve this answer
3  
This might be helpful for the next time, but it won't help the OP to understand if the current command is frozen or not. –  Francesco Turco Nov 2 '12 at 13:11
add comment

Sometimes you may not be able to use the INFO or USR1 signal because the stderr stream of the dd process is not accessible (e.g. because the terminal in which it was executed was already closed). In this case, a workaround is to do the following (tested on FreeBSD, may be slightly different on Linux):

  1. Use iostat to estimate the average write rate (MB/s) to the target device, e.g.:

    iostat -d -w30 ada0

    Substitute your target device name for ada0 here, and wait a minute for it to give a couple results. The "w" parameter determines how many seconds between samples. Increasing it will give a better average estimate with less variance, but you'll have to wait longer.

  2. Use ps to determine how long dd has been running:

    ps -xo etime,command | grep dd

    Convert this to seconds to get total seconds of runtime.

  3. Multiply total seconds of runtime by average write rate to get total transferred MB.
  4. Get the device size in MB with:

    grep ada0 /var/run/dmesg.boot

    Substitute your target device name for ada0. Divide the result by the average write rate to get the total transfer time in seconds. Subtract the time it's been running so far to get time remaining.

This strategy only works if dd has been writing continuously at the current average write rate since it began. If other processes are competing for the CPU or I/O resources (including the I/O bus) then it may reduce the transfer rate.

share|improve this answer
add comment

What does the hdd-led suggest?

Normally, if a program terminates, you get back the prompt.

share|improve this answer
    
Clearly it hasn't terminated; he's worried that it's frozen –  Michael Mrozek Apr 13 '11 at 17:55
    
But the led wouldn't blink, would it? –  user unknown Apr 13 '11 at 18:01
    
@user No, that part made sense; I was talking about your second sentence –  Michael Mrozek Apr 13 '11 at 18:02
    
@user but the LED could blink for other reasons... also some programs will not give you back the prompt not because they are frozen, but because you didn't tell them to do what you think you did. –  xenoterracide Apr 14 '11 at 14:07
    
The led blinking for 12 hours? Did you experience such a thing? –  user unknown Apr 14 '11 at 17:24
show 2 more comments

Your Answer

 
discard

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.