Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
Edited: do not run this to test it unless you want to destroy data.
Could someone help me understand what I got?
dd if=/dev/zero of=/dev/sda bs=4096 count=4096
Q: Why specifically 4096 for count?
dd if=/dev/zero of=/dev/sda bs=512 count=4096 seek=$(expr blockdev --getsz /dev/sda - 4096)
Q: What exactly does this do?
Warning; Above code will render some/all specified device/disk's data useless!
dd if=/dev/zero of=/dev/sda bs=4096 count=4096 Q: why 4096 is particularly used for counter?
This will zero out the first 16 MiB of the drive. 16 MiB is probably more than enough to nuke any "start of disk" structures while being small enough that it won't take very long.
dd if=/dev/zero of=/dev/sda bs=512 count=4096 seek=$(expr blockdev --getsz /dev/sda - 4096)
Q: What does this exactly?
blockdev --getsz gets the size of the block device in "512 byte sectors". So this command looks like it was intended to zero out the last 2 MiB of the drive.
Unfortunately this command is broken syntax wise. I expect the command was originally intended to be
dd if=/dev/zero of=/dev/sda bs=512 count=4096 seek=$(expr `blockdev --getsz /dev/sda` - 4096)
and the backticks got lost somewhere along the line of people copy/pasting it between different environments.
Old partition tables, LVM metadata, raid metadata etc can cause problems when reusing a drive. Zeroing out sections at the start and end of the drive will generally avoid these problems while being much faster than zeroing out the whole drive.
expr blockdev --getsz /dev/sda - 4096 would be a syntax error of expr. I think the intended command was ...seek="$(expr "$(blockdev --getsz /dev/sda)" - 4096)". Or better: ...seek="$(($(blockdev --getsz /dev/sda) - 4096))"
Jun 8, 2017 at 14:44
This will erase the first 4096*4096=16MB and last 512*4096=2MB of your hard drive, which contain important structures useful for recovery. I assume this code was posted maliciously.
I've never encounter a situation where explicitly specifying a count other than 1 was useful. I have erased the first block if I wanted to ensure I wasn't leaving any traces of the MBR behind ...
sda. More likely sdb or sdc. But I may be wrong of course...
Those commands will overwrite your sda device with zeroes -- the first one will do the first 16MB (block size of 4096 and count of 4096 blocks) and the 2nd one will overwrite the last 2MB (512 block size with 4096 blocks) with zeroes. (it's not technically erasing, and that relates to my first point below.)
(that was the part already mentioned in other answers, including it here for completeness)
Another thing that is worth mentioning is that the block size does have effects, but those are generally only seen on high-volume operations. The most efficient (fastest) way to execute the command is if the block size of the command matches the access size of the device, otherwise time is wasted.
If you're interested, you can try creating a file with a million 1-block chunks, and a file with 1 million block chunks and see the difference:
[user@host tmp]$ time dd if=/dev/zero of=/tmp/test1 bs=1 count=1000000
1000000+0 records in
1000000+0 records out
1000000 bytes (1.0 MB) copied, 2.44439 s, 409 kB/s
real 0m2.447s
user 0m0.177s
sys 0m2.269s
[user@host tmp]$ time dd if=/dev/zero of=/tmp/test2 bs=1000000 count=1
1+0 records in
1+0 records out
1000000 bytes (1.0 MB) copied, 0.00155357 s, 644 MB/s
real 0m0.003s
user 0m0.001s
sys 0m0.002s
[user@host tmp]$ ls -al test*
-rw-rw---- 1 user grp 1000000 Apr 8 15:51 test1
-rw-rw---- 1 user grp 1000000 Apr 8 15:51 test2
As you can see, blocksize has a massive impact on efficiency. That's perhaps a sidebar to the OP, but I feel that it's still relevant.
TL;DR: Don't execute arbitrary code you find on the net, or that someone you don't trust gives you. It'll ruin your day.
Don't execute arbitrary code you find on the net line
Apr 9, 2016 at 14:48
WARNING: dd if=/dev/zero of=/dev/ is used to clean a drive or device before forensically copying data. The drive or device must always be sanitized before copying information from a system under forensic investigation to mitigate cross contamination. Therefore, it is not a bad command, the end-user must understand what it is used for or they will destroy their data. If this is what you desire then to verify the zero write operation do dd if=/dev/sda | hexdump -C | head.
Source: A Practical Guide to Computer Forensics Investigations by Dr Darren Hayes
Others have explained what they do, so I'll skip that.
The point in dd having seperate bs and count argument is that bs controls how much is written at a time. Specifying really large values for bs will require a really large buffer in the program, and specifying values less than the block size of the device will be slow because the kernel has to build an entire block to write to the device (in cases like this it can probably buffer the writes until there a complete block, in other cases it might have to read what's already on the disc). As the two commands use different values for bs, that leads me to think that you might have found them on two different sites. Hard discs used to have a block size of 512 bytes, corresponding to the bs=512 of the latter command, but some (6-8 I think) years ago they started making discs with a block size of 4096 bytes, making bs=4096 a better choice for modern discs.
bs is much higher than that. A single SATA command can read or write multiple sectors, so the kernel merges I/Os before sending them out. Anywhere from bs=64k to bs=1024k is reasonable (L3 cache size is often 4-8MiB). I often use bs=128k, which is half of L2 cache size on modern Intel CPUs. (dd includes two memcpy operations: in the read(2) from the source (even if it's /dev/zero), and the write(2). IIRC, sdd had an option to write zeros, which would save a bit of CPU time. Really only relevant if the destination is something other than a disk).
Apr 10, 2016 at 2:32
iostat -x 4 or something, and note the rrqm/s (read-requests merged per second) and wrqm/s columns.
Apr 10, 2016 at 2:33
I use dd if=/dev/zero of=/dev/sdX oflag=sync to test quality of an inserted USB drive or MicroSD card BEFORE I actually use it with gparted, fdisk, or dd with a disk image. I think that this is a prudent idea, especially with MicroSD media which has a poor history of quality.
Of course, be careful with of=sdX because there is no forgiveness with an accidental disk wipe. Verify that X= drive letter of intended target.
Yes it does wipe the beginning and end of the disk, to seemingly arbitrary boundaries. They seem overly complex and risk prone to be outside of a script. The zones are not copied to a file first, for instance.
As well as LVM and other schemes, there are third party products that copy allocation data to the end of the disk for redundancy. Without knowing what this disk was used for, the leading wipe seems excessive.
It is important to understand that disks do not always use standard partitioning and file systems. This may be a flash drive used with custom/proprietary hardware.
In a perfect world there would be a supervisor routine in the disk firmware to zero every "page", but then we would be assuming SSD.
4096 is a good block size, possibly the count is a typo, but there may be a good reason. Nobody using these should ever be asking what they do. You absolutely positively must know. Start with man dd.
Since the question was posted the backticks have been replaced with the equivalent (for the purpose) $(...) syntax.
Such arithmetic suggests the geometry of the disk is expected to vary, since a user of dd would be sophisticated enough to know the integer value, this is as unnecessary as "lines" arithmetic in a terminal.
It is also suggestive of this being copied. If it was copied, it has been modified. The count in the second statement? Why this limit and not 8? How far can it get?
