Solved How to see if a command is running

vince66

vince66

Hello guys,

I've launched the command:

dd if=/dev/zero of=/dev/da4

da4 is a 1TB usb 3.0 external hard disk attached to the usb 3.0 port of my PC.

It's been 24 hours ... the led of the external hard disk keeps flashing.
Can you tell me please how can I see if the usb communication is active and the dd command is actually working?

Thanks very much.

I hope to hear you soon.

Bye bye !!!
 
vince66 said:
Can you tell me please how can I see if the usb communication is active and the dd command is actually working?
Click to expand...
man dd
If dd receives a SIGINT signal, the current input and output block counts will be written to the standard error output in the same format as the standard completion message and dd will exit.
Click to expand...
try as root: edit:
Code: 
kill -SIGINFO $(pgrep -x -n dd)
 
Last edited:
dR3b didn't you mean SIGINT insted of SIGUSR1 ? Anyway, that will terminate the process.

You could try to trace the syscalls it does with truss -p $PID.
 
Try to find a way to measure the performance of the copy. If Control-T works (meaning: you still have the shell window open), that would be easiest, since it gives you performance in bytes/second. If not, you'll have to do iostat, as shown above.

Then extrapolate to the size of the disk (the whole disk is so many terabytes, you are doing so many megabytes per second, there are so many seconds in each minute/hour/day), and estimate how long it will take.

Why? Because the way you are doing the writing is insane: You are asking dd to write 512-byte blocks at a time, since you didn't specify a block size. For flash storage, a block size of 512 bytes means that the flash has to do read-modify-erase-write cycles all the time. It also means that all the SATA overhead happens for every block. Depending how good the FTL (flash translation layer) in your SSD is, there are some optimizations it can make (sequentiality detector, log-structure bypass, and so on), but even with all internal optimizations, performance will never be great. I think your performance will be very low, probably single digits MB/s. At that performance, the writing will take multiple days. You are also wearing out the SSD faster, since it may have to do a lot of extra erase/write cycles.

If the write will take a long time, try aborting it, and restart it with an extra option: "bs=... large number". I would go for something like "bs=8m" and write 8 MiB blocks at a time. With that, your performance will probably be around 100-200 MB/s, and the writing will finish much faster.
 
ljboiler said:
you can type ctrl-T
Click to expand...
SirDice said:
Just hit CTRL-T
Click to expand...

I hit ctrl-T different times.

Code: 
load: 0.04  cmd: dd 1328 [physwr]  119012.56r  218.89u  1386.27s  1%  2160k
155690994+0 records in
155690994+0 records out
79713788928 bytes transferred in 119012.558562 secs (669793 bytes/sec)

load: 0.20  cmd: dd 1328 [physwr]  187008.51r  344.87u  2186.49s  0%  2164k
244641000+0 records in
244641000+0 records out
125256232960 bytes transferred in 187008.515607 secs (669789 bytes/sec)

can you tell me why the cpu load is 0% ?
More: the writing rate is about 669700 byte/sec .... so should be very time expensive zeroes 1TB hard disk in this condition.
 
ralphbsz said:
If the write will take a long time, try aborting it, and restart it with an extra option: "bs=... large number".
Click to expand...

Hello Ralph !

I've received your reply just few second after I've posted my analysis of the ctrl-T.

I'm perfectly agree with you .... the way I'm doing the writing is insane.
I stop and repeat the dd.

Thanks very much !!!
 
vince66 said:
can you tell me why the cpu load is 0% ?
Click to expand...
Because it's not doing much. Writing a bunch of zeroes on a disk is peanuts for the CPU.

vince66 said:
More: the writing rate is about 669700 byte/sec .... so should be very time expensive zeroes 1TB hard disk in this condition.
Click to expand...
No, not really. It'll just take like a billion years to finish.

May I ask why on Earth you're doing what you're doing? It sounds a bit pointless.
 
Beastie said:
It'll just take like a billion years to finish.
Click to expand...

Surely.
It has been a my idiot idea.

As ralphbsz wrote the correct way is to use larger bs.

ralphbsz said:
If the write will take a long time, try aborting it, and restart it with an extra option: "bs=... large number".
Click to expand...

I've set bs=8m and now the rate shown by ctrl-T is: 106727755 bytes/sec.

My apologize.

NOTE: large bs are not good if the disk has corrupted sectors. This is important when you image a drive with dd and it is why I avoid to use large bs values.
However, to be sure, is better if ralphbsz confirms this my sentence.

Bye bye !!
 
Do you know what means:

physwr

so it appears running ctrl-T ?

It seems that (see what do all the states in top mean?):

These states aren't documented, mainly because the strings that are used are spread throughout the tree and are subject to change. "kqread" just means a process is blocked on kqueue(2). "select" means a process is blocked on select(2). "nanslp" means a process sleeping on a nanosleep(2) call.

Thanks very much.
 
Must be "PHYSical WRite". Makes perfect sense.

About your problem of wanting to use really small blocks (so you get around sector errors), but also wanting to use really large blocks (so IO goes faster): there is a good compromise for that. Namely a version of dd that at first tries to use very large blocks. When it gets an IO error, it retries the failed IO with smaller and smaller IOs, until it gets "most" of the area taken care of. Changing the existing "dd" source code to do so would be quite a bit of work, probably many hours for an expert. But I know that some version of a copying program exists that is already capable of doing this, but I don't remember which one it is. If you look around for something like "dd version with error handling", you might find it.
 
vince66 said:
NOTE: large bs are not good if the disk has corrupted sectors. This is important when you image a drive with dd and it is why I avoid to use large bs values.
Click to expand...
If the disk is corrupted and causing problems with dd(1) the disk should be trashed. If you need to image an corrupted disk (for recovery purposes) you should use sysutils/ddrescue.
 
You must log in or register to reply here.
Back
Top