[SOLVED] dd

anutosho · 03-20-2018, 11:48 AM

Hi together, today I wanted to write a CD image to a USB key, using dd. I noticed that the write is relatively slow. When I started the gkrellm monitor I noticed that dd is doing excessive reads from the target (the USB stick). Write operations took place only between these read operations, see attached screenshot (oh, no file attachments here?...) Any idea what's happening here?

MensaWater · 03-20-2018, 12:32 PM

You don't say what blocksize (if any) or other options you specified.

This link suggests 4M and also notes you need to be sure the thumb drive is unmounted (not ejected):

Code:

dd bs=4M if=[ur .iso] of=/dev/sd[that 1 letter]

The link talks about a Windows CD but I doubt that matters if you're doing a dd.

anutosho · 03-20-2018, 12:40 PM

Quote:

Originally Posted by MensaWater

You don't say what blocksize (if any) or other options you specified.

I didn't because I did not specify any special blocksize, so the standard is used.
I don't think the drive was mounted (cannot be 100% sure, though)
I remember having this issue with hard disks, too. Sometimes it helped to just cancel and restart the dd process.

MensaWater · 03-20-2018, 03:01 PM

Quote:

Originally Posted by anutosho

the standard is used.

The default might be painfully slow for various reasons. Use of an appropriate bs helps speed things up AND reduce the number of reads and writes. I suggested the 4M as the post that suggested it talked about CD to usb so seemed relevant.

For more details reading on setting appropriate block size you might try these:
http://blog.tdg5.com/tuning-dd-block-size/
https://serverfault.com/questions/65...rove-the-speed

AwesomeMachine · 03-20-2018, 04:54 PM

I think dd reads three times as much as it writes. It reads into a buffer, then it compares the buffer to the source, then it writes the buffer to the target. And it probably interleaves several of those operations.

syg00 · 03-20-2018, 09:19 PM

It looks like it does what you'd expect - reads sectors, and writes them out. I put perf probes on libc read and write, and ran a small dd - count = 100000. Here's the result, redacted for brevity;

Code:

[root@xps ~]# cat read.001 
# event histogram
#
# trigger info: hist:keys=common_pid.execname:vals=hitcount:sort=hitcount:size=2048 [active]
#

...
{ common_pid: gnome-shell     [      1700] } hitcount:        470
{ common_pid: dd              [     17140] } hitcount:     100000

[root@xps ~]# cat write.001 
# event histogram
#
# trigger info: hist:keys=common_pid.execname:vals=hitcount:sort=hitcount:size=2048 [active]
#

...
{ common_pid: bash            [     16376] } hitcount:        151
{ common_pid: dd              [     17140] } hitcount:     100003

The effects the OP is seeing would be due to the I/O scheduler and caching effects (hence cancel/restart being faster).

anutosho · 03-20-2018, 11:34 PM

Thanks a lot for your tips and insights.
I think this could be regarded as solved.