2

Consider the following two commands both creating a dumb 1KB file

dd if=/dev/urandom of=test.file bs=1024 count=1

dd if=/dev/urandom of=test.file bs=1 count=1024

The first command uses a block size of 1024 bytes and a block count of 1, the second does the other way round.

My guess is that there is no difference and limiting block size is a RAM related issue: you can't have a block size larger than available memory.

Are there any special cases when I would want or have to use the first case over the second one? And vise versa?

7

As you seem to basically understand, the first version does one read of 1024 bytes, and then writes however many bytes came back from the read, while the second version does 1024 reads and writes of one byte each.  When copying ordinary files, the larger block size (resulting in the smaller number of I/Os) may be marginally more efficient. This is probably true for /dev/urandom as well.

But you need to be careful when using dd on special files (i.e., devices).  For example,

dd  if=(whatever input)  of=(a magnetic tape device)  bs=1024  count=1

will write one tape block of 1024 bytes; dd … bs=1 count=1024 will write 1024 blocks of one byte each.  These are not the same; the 1024 small blocks will take up more room on the tape than the one large block, because of inter-record gaps, and may cause problems for reading the tape.  More relevant to your question, if you read (if=) from /dev/random, it will return only as many high-entropy bytes as are available.  So, in the first version, you might get fewer than 1024 bytes.  But, if you try to read one byte, and the entropy pool is empty, the read will block (i.e., wait) until data are available, so the second version would be guaranteed to get you 1024 bytes (although it may take an arbitrarily long amount of time).

To enlarge on the point about the tape drive:

dd  if=(appropriate input)  of=(a magnetic tape device)  bs=512  count=2

will write two tape blocks of 512 bytes.  A subsequent

dd  if=(magnetic tape device)  of=(whatever)  bs=1024  count=1

might read only the first block; i.e., the first 512 bytes.

And (named) pipes may exhibit the same problem as /dev/random– a large read will return only as bytes as are available; so, again, in the first version, you might get fewer than 1024 bytes. But, if you try to read one byte at a time, the read will wait until data are available, so the second version would be guaranteed to get you 1024 bytes (or at least read until EOF).

  • As an illustration of this, try to do a strace of both dd commands. It will clearly show that one does one read/write while the other does 1024 consequtive read/writes. – agtoever Aug 16 '14 at 5:52

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.