2

While dding a CentOS 7 x86_64 DVD image to a USB drive (sdb), I monitored the progress with iostat.

It kept alternating between mostly writing to the USB drive:

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              18,00       380,00        28,00        380         28
sdb              79,00        16,00      9000,00         16       9000

And reading from it hard disk and USB drive simultaneously:

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              53,00      5180,00         0,00       5180          0
sdb            1329,00      5316,00         0,00       5316          0

There was nothing else going on in the machine and, when dd stopped, the disks became idle.

Is it some sort of internal checksumming process in dd?

Anything inherent to USB drives' drivers in Linux 3.16.0?

migrated from serverfault.com Dec 3 '14 at 0:56

This question came from our site for system and network administrators.

  • Could you please provide the exact command being typed? – Marcelo Dec 3 '14 at 1:03
  • I looked at the source code for dd and there was nothing obvious. There is no checksumming occurring. – Mark Wagner Dec 3 '14 at 19:22
1

I encountered a similar situation when secure-wiping an external (USB 2.0) hard disk: long periods of reads followed by a few seconds of high throughput writes, when I expected 100% writes. I used pv to show me an overall write speed (see command below) and I was getting an average of 10MB/s, in bursts of 14MB/s for ~10 seconds followed by a few kB/s. My iostat output looked very much like yours.

It turned out that the issue was my much-too-small dd block size (512 bytes). I suspect that what's happening is that the kernel was reading blocks into its 1k-per-block buffers so that dd can overwrite 512 bytes at a time, which then got flushed. I'm not a kernel expert so that' just a guess.

I can say that pumping up my dd block size to 72K made a huge difference. I am now seeing >40MB/s sustained writes. This is pretty close to the theoretical maximum that USB 2.0 can provide (480Kb/s, not counting USB overhead) and also pretty close to the maximum sustained write speed that this 10 year old disk can achieve (something like 55MB/s), so I'm satisfied that this is more or less bare-metal speed.

Here's the command I'm using to wipe the drive:

openssl enc -aes-256-ctr -pass \
pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" \
-nosalt </dev/zero \
| pv -bartpes 160041885696 -B 128K \
| dd bs=72K count=2170707 of=/dev/sdf iflag=fullblock

Lines 1-3 pipe /dev/zero through AES-256-CTR encryption, using a password generated from /dev/urandom. So it's a stream of cryptographically random garbage.

Line 4 shows progress, given the 160GB drive's byte count and using a transfer buffer size in pv of 128KiB.

Line 5 uses a block size that I picked using a calculator, trying to find the largest multiple of 512 that was a factor of the total # of bytes of the drive. iflag=fullblock makes dd read repeatedly into its buffer until it has 1 full block before writing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.