On 04/28/2014 03:51 PM, Bernhard Voelker wrote: > On 04/26/2014 11:46 AM, Pádraig Brady wrote: >>> Everything seems to work fine as long as I am not trying to interrupt >>> this process (using CTRL-C). >>> Only in this case everything just freezes for some time (for about >>> 1 minute the terminal is blocked) [...] > ___^^^^^^^^ > > >> dd does catch ^C, but it processes pending interrupts before each read() and >> write(), >> and those read() and write() calls should return with EINTR. >> >> Therefore it seems like the kernel is blocking these signals? > > Hmm, although the kernel may be blocking, it sounds very strange > that the blocking takes one minute. The OP used only bs=4M with > a local file on disk as input file, and an SD card's device as output > file. Even if /dev/sdc was on USB1.1 (12MBit/s), then 4M/minute > sounds very slow. Could it be something else? > Maybe an "strace -tt dd ..." could shed some light on this.
Note the kernel may cache lots more than 4M before it even starts writing out to the device. I think there maybe some very recent improvements to the kernel to address at least the excessive caching part of the issue, though if there are large pending writes to slow devices the kernel can still block for a long time. Pádraig.
