Will this command: dd if=/dev/zero of=/dev/sda bs=1M succeed if the dd command was originally on /dev/sda? Will this complete because dd is in memory at that time?

6 Answers 6


There are three things which can happen:

  1. The command starts, runs till completion and you get dropped back to a prompt. Since the disk is effectively wiped at you can't do much after that, though you might get lucky with some shell build-in commands.
  2. The command starts. At some point it gets paged out due to memory pressure. Normally this is not a problem because parts of it can just be reloaded from disk (unchanged data) of from swap. However if you just wiped these then the dd command will fail partially though filling the disk.
  3. The third option is something from BSDs. The MBR on a mounted disk is protected from overwriting. Even if you run the command as root. There are dozens of Linux distributions, all being just slightly different. It is quite possible that some of them emulate this.

So far for the theory. Now for a practical test.

I installed a fresh Ubuntu 12.10 on a VM. (VMware workstation on win7-x64, using default options and a 10 GB virtual disk).

The dd command completed successfully and I got dropped back at what seemed a working prompt. I could enter new commands, though they would fail for obvious reasons.

Screenshot of the Ubuntu VM after wiping the disk

  • 9
    Big +1 for the practical test! Apr 23, 2013 at 21:42
  • 10
    I see Segmentation fault and you claim that it completed successfully...?
    – Alvin Wong
    Apr 24, 2013 at 2:10
  • 1
    Aye. It made the disk unreadable. I think that was the goal. For secure erases you really should try something else (such as the secure erase command).
    – Hennes
    Apr 24, 2013 at 15:17
  • one of the best answers I have ever gotten. Thanks!
    – agz
    Apr 25, 2013 at 1:17

A quick experiment in a virtual machine using Damn Small Linux indicates the dd command indeed completes, as expected; the program is initially loaded into memory to run and it makes very little sense to load the executable again and again during the process. Eventually, dd will exit and report 'no space left on device'.

Afterwards, the operating system seems to function normally at first sight, but hangs after the first command it can no longer execute for obvious reasons and becomes unresponsive. A brief inspection of the hard drive contents shows the partition has indeed been zeroed.


From the mmap page on Linux:

MAP_SHARED Share this mapping.  Updates to the mapping are visible to other processes that map this  file,
           and  are  carried  through  to the underlying file.  The file may not actually be updated until
           msync(2) or munmap() is called.

           Create a private copy-on-write mapping.  Updates to the mapping are not visible to other  pro‐
           cesses  mapping  the  same  file,  and  are  not carried through to the underlying file.  It is
           unspecified whether changes made to the file after the mmap() call are visible  in    mapped

Executables are mapped to memory by the kernel via an internal call to the mmap function. A MAP_PRIVATE type mapping is requested (look in fs/binfmt_elf.c of the kernel source tree).

So it boils down to the behavior of mmap: whether changes in the file, or the underlying block device to which that file is referenced, are propagated back to the pages of the mapping which have already been paged in and are present.

That page is based on API standards, rather than kernel behavior, hence the "unspecified". The actual behavior is that changes to the file are not propagated back to already present pages. Of course, if the program suddenly jumps to a page of code which has not been paged in, and the erasure has already taken place, then it will get a page of all zeros.

But, quite probably, by the time dd erases itself, it has paged in all the pages of code it needs to continue the erasure loop. There is the possibility that once the loop terminates, it may hit some code that is in a not present page: like, say a function spans across a page boundary, so to reach the return instruction, a page has to be fetched.

But that page may be cached from a previous dd invocation, too.


Yes. Of course, it'll also cost you most of your filesystem, but presumably you already know that...


I made a mistake recently. I intended to dd a 2 GB img onto SD Card, but did it to sda by mistake dd if=rasberrypi.img of=/dev/sda . Realized my mistake and canceled the dd, but by then ~600MB (on a disk with ~500GB used) had been written. Partition table was ruined.

The desktop (with 10 GB memory and up for weeks) continued functioning for few hours asif nothing happened. Managed to get recently changed important files into dropbox, browsed in chrome normally. In fact i could run the dd to SD card as i had originally wanted, worked fine.

After a couple of hours, my filesystem went into read only mode, and random programs started dieing. I was sshed into many other systems, i could continue using those sessions, but making new session gave error that it cant find the ssh program. At this time i could switch open tabs in chrome, but the contents of the tabs seem to have "hung". If i refresh, i get white screen forever. rsyslogd was taking 100% cpu (1 core) for some reason, probably it was confused why it couldn't flush logs to disk... maybe.

I had a 350 MB video opened (and paused) in VLC, i could still play it, and skip to any part of the video. Probably since its a recent download.

I could shut down the system normally using GUI, no errors.

So this doesnt answer your question exactly, but tells what happens if u wipe out begining of the disk..

Most of the things on the disk can still be recoverable, but im not gonna bother since (hopefully) everything i care about is backed up.


Most likely it will not complete, since some other executing component will request a file that's missing and panic the kernel. if you really want to zero the disk, use a live CD; otherwise you can never guarantee the result.

  • 2
    Requesting a file that's missing won't panic the kernel. If it did, machines would crash if they had just one unreliable disk. Apr 23, 2013 at 20:31
  • @DAvid Schwartz, if that were the case, then #rm -rf / would actually delete the entire file system. I know from experiments that that is not the case. the system cannot stay running long entirely from ram unless some kind of ramdisk technology is implemented, which is not standard. Apr 24, 2013 at 11:32
  • @FrankThomas: Did the kernel panic? Apr 24, 2013 at 15:13
  • yes, blackscreen shutdown. Apr 24, 2013 at 16:23

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.