dd can create random files of any size
I needed to generate files of a certain size for performance testing - their contents were irrelevant. The
dd
utility was perfect for the task.Creating a 100MB file full of random binary data
dd if=/dev/urandom \
of=a_file \
bs=1048576 \
count=100
- dd
- A command-line utility for copying and converting data
- if
- the input file
- /dev/urandom
- takes advantage of UNIX's philosophy of treating all resources as files. This is a standard UNIX utility (it generates random bytes), but to dd it works as if it was a file
- of
- the output file
- a_file
- in this case we generate an actual file
- bs
- block size; the amount of data to read/write at once. It should be a power of 2
- 1048576
- That is the closest power of 2 to 1 MB
- count
- How many blocks to write
- 100
- We are creating a 100MB file full of gibberish
Creating a 1Kb file full of random ASCII data
The same command can be adapted to create ASCII data, by piping another command that translates the output to ASCII
dd if=/dev/urandom \
bs=1 \
count=1024 \
2>/dev/null \
| base64 \
| head -c 1024 \
> a_file.txt
- dd if=/dev/urandom
- The same command as above (except that there is no output file this time)
- bs=1 count=1024
- this time just 1 byte of data at the time, for a total of 1024 bytes
- 2>/dev/null
- if there are any errors or debugging info, just send them to the "black hole" (/dev/null) so we don't see them
- | base64
- send the output to the util `base64`, which converts binary data into text. It is commonly used to encode, say, images in email attachments
- | head
- send the output to the util `head`, which takes only the initial part of any ouput and discards the rest. This is needed, because base64 makes the output larger by about 33% (there is a reason why we use binary and not text to encode data)
- -c 1024
- in this case only take the first kilobyte (note how it matches the initial count)