Short answer: it'll do roughly what you want and then nothing will work. Using dd
you're operating at a level below the filesystem which means that any constraints which would apply there are no longer relevant (this doesn't mean that the kernel couldn't prevent you doing this - but it doesn't). Some content from the filesystem is already in memory, for example the kernel and the dd
program itself, and some will be in cache. There is a possibility that if the system is in multi-user mode some files may be written back while the dd
is in progress, assuming that they actually have changed, and if you're under memory pressure some pages from there may also get swapped out (they should be encrypted and thus unusable after reboot).
Most commands you'd issue following this - including reboot
- would not be in the cache and so would not work. So if you're in single user mode, it'll do extremely well, if you're in multiuser mode it'll wipe the vast majority of data. Ideally you should do it booted from some other medium (even stopping on the initrd perhaps) so that you can be sure where all the writes are coming from.
If you want a secure wipe, this won't do the job because there will still be some traces of the original data remaining if you just zero it. Typically you'd want up to three random writes, which would mean copying from /dev/urandom
instead of /dev/zero
- much slower but safer. Some may suggest that you use /dev/random
which is the device for "pure" random data - no pseudo-random - but for this purpose the chance of somebody managing to crack the PRNG seed and successfully mask out the data is essentially negligible.
If you're really paranoid, you need to throw the storage device into a furnace so that it demagnetises/discharges.