ddCopy and convert raw data block by block
dd copies bytes from an input to an output in fixed-size blocks, with no idea of files or filesystems. That makes it the tool for disk images, writing ISOs to USB sticks, quick throughput tests and creating test or swap files, and also one of the easiest ways to destroy a disk.
dd if=INPUT of=OUTPUT [bs=SIZE] [count=N] [skip=N] [seek=N] [status=progress] [conv=...] [iflag/oflag=...]You need a 100 MiB file of zeros to test an upload limit, and want to understand the three lines dd prints.
sudo dddd itself; root because it reads a raw block device.
dd is a loop around two system calls: read() bs bytes from if, write() them to of, count times. It knows nothing about filesystems: for a disk it copies every sector, used or not, partition table included. Each read that returned a full block counts as '+0' in 'records in'; a short read (end of file, pipe) counts as a partial record, which is why you see 2+1. By default writes land in the page cache and dd reports a speed that is really memory speed; oflag=direct opens the output with O_DIRECT to bypass the cache, conv=fsync or fdatasync flushes at the end, and oflag=sync waits after every write. skip and seek move the input and output offsets in blocks, conv=notrunc keeps the rest of an existing output file. The old nickname 'disk destroyer' is earned: there is no confirmation, and of=/dev/sdX overwrites whatever is there.
if= / of=Input and output file or device (default stdin/stdout)bs=SIZERead and write SIZE bytes at a time: 4K, 1M, 4Mcount=NCopy only N blocksskip=N / seek=NSkip N blocks of input / output before startingstatus=progressLive progress; status=none for silenceconv=fsync / fdatasyncFlush the output to disk before exitingconv=notruncDon't truncate the output file (patch bytes in place)conv=sparseSeek over all-zero blocks instead of writing themconv=noerror,syncKeep going on read errors, pad bad blocks with zerosoflag=direct / iflag=directBypass the page cache (honest disk benchmarks)oflag=syncSynchronous writes: wait for each block to hit the disksudo dd if=backup.img of=/dev/nvme1n1 when you meant the other directiondd never asks. Swapping if and of, or one wrong letter in a device name, overwrites a disk instantly.
Run lsblk first, re-read the command, and prefer of=/dev/disk/by-id/... namesBenchmarking a disk with plain dd if=/dev/zero of=fileThe data lands in the page cache and dd reports RAM speed.
dd ... oflag=direct (or conv=fdatasync), better still fiodd with the default block size on a large diskbs=512 means millions of tiny system calls; copying is many times slower.
bs=4M status=progressImaging a mounted, active filesystem with ddBlocks change during the copy, so the image is inconsistent and may not mount.
Unmount (or freeze with fsfreeze, or use a cloud snapshot) before imagingTry these on a Linux machine of your own. Each task has a hint and a solution.
Create a 50 MiB file of zeros called zero.img and a 5 MiB file of random data called rand.bin.
Write the first 512 bytes of zero.img to a separate file and confirm its size.
Measure sequential write speed in your home directory honestly, bypassing the page cache, then clean up.
Copy rand.bin with dd and prove the copy is identical.
ddCopy and convert raw data block by block
dd copies bytes from an input to an output in fixed-size blocks, with no idea of files or filesystems. That makes it the tool for disk images, writing ISOs to USB sticks, quick throughput tests and creating test or swap files, and also one of the easiest ways to destroy a disk.
dd if=INPUT of=OUTPUT [bs=SIZE] [count=N] [skip=N] [seek=N] [status=progress] [conv=...] [iflag/oflag=...]You need a 100 MiB file of zeros to test an upload limit, and want to understand the three lines dd prints.
sudo dddd itself; root because it reads a raw block device.
dd is a loop around two system calls: read() bs bytes from if, write() them to of, count times. It knows nothing about filesystems: for a disk it copies every sector, used or not, partition table included. Each read that returned a full block counts as '+0' in 'records in'; a short read (end of file, pipe) counts as a partial record, which is why you see 2+1. By default writes land in the page cache and dd reports a speed that is really memory speed; oflag=direct opens the output with O_DIRECT to bypass the cache, conv=fsync or fdatasync flushes at the end, and oflag=sync waits after every write. skip and seek move the input and output offsets in blocks, conv=notrunc keeps the rest of an existing output file. The old nickname 'disk destroyer' is earned: there is no confirmation, and of=/dev/sdX overwrites whatever is there.
if= / of=Input and output file or device (default stdin/stdout)bs=SIZERead and write SIZE bytes at a time: 4K, 1M, 4Mcount=NCopy only N blocksskip=N / seek=NSkip N blocks of input / output before startingstatus=progressLive progress; status=none for silenceconv=fsync / fdatasyncFlush the output to disk before exitingconv=notruncDon't truncate the output file (patch bytes in place)conv=sparseSeek over all-zero blocks instead of writing themconv=noerror,syncKeep going on read errors, pad bad blocks with zerosoflag=direct / iflag=directBypass the page cache (honest disk benchmarks)oflag=syncSynchronous writes: wait for each block to hit the disksudo dd if=backup.img of=/dev/nvme1n1 when you meant the other directiondd never asks. Swapping if and of, or one wrong letter in a device name, overwrites a disk instantly.
Run lsblk first, re-read the command, and prefer of=/dev/disk/by-id/... namesBenchmarking a disk with plain dd if=/dev/zero of=fileThe data lands in the page cache and dd reports RAM speed.
dd ... oflag=direct (or conv=fdatasync), better still fiodd with the default block size on a large diskbs=512 means millions of tiny system calls; copying is many times slower.
bs=4M status=progressImaging a mounted, active filesystem with ddBlocks change during the copy, so the image is inconsistent and may not mount.
Unmount (or freeze with fsfreeze, or use a cloud snapshot) before imagingTry these on a Linux machine of your own. Each task has a hint and a solution.
Create a 50 MiB file of zeros called zero.img and a 5 MiB file of random data called rand.bin.
Write the first 512 bytes of zero.img to a separate file and confirm its size.
Measure sequential write speed in your home directory honestly, bypassing the page cache, then clean up.
Copy rand.bin with dd and prove the copy is identical.