the dd command you used will fill the current partition only.

/dev/sda on the other hand refers to the whole hard drive.

IF this is accurate, THEN I don't 'understand' 'how Linux works' (assuming 1 1T partition)

sorry guy: what did you quote?
here is a possible explanation: http://prefetch.net/blog/index.php/2...hosts-with-dd/

If you want to wipe the whole disk.

# dd if=/dev/zero of=/dev/sdXYZdiskXYZ bs=1M
# cmp /dev/zero /dev/sdXYZdiskXYZ

Where sdXYZdiskXYZ is probably not the actual name of your device. It should fail at the end of device, otherwise it didn't take. Some media fails to read only and you can NEVER delete the data. Outside of physically destroying the media. Data recovery tools like photorec / testdisk can read the entire device and reform media that was not overwritten. If you want to make those tools mostly useless, use encrypted file systems and delete your keys. SSDs tend to have reserve write-able areas and swap out used areas for them when issues or use deem it necessary. You lose access to "delete" that data, but it's still technically there. Some SSDs are encrypted by hardware with ways to delete their keys that (in theory) deletes the data by removing the ability to (easily) decrypt the data. It depends on where you place your "trust".

Sorry for my writing... it's from #8, bottom. The [...] are my interpretation of what was done.
The only difference is the `rm junk` (but I don't think that changes the issue here)
I thought of 'sparse' files, but I didn't think `dd if=/dev/zero of=junk` would cause them.

My interpretation of the complete scenario of what OP did, may be incomplete/incorrect.
OP seemed to be referring to a 'normally' running system, ext4, but didn't say what distro,
so wasn't writing direct to the /dev/sd..., just a file, filling fs. Maybe OP will clarify.
The goal seemed to have been: to zero-out all disk blocks containing 'deleted' data, so no 'typical' recovery process could find pieces of 'old data' (or to verify this, before&after).

I 'picked up on' the [plea]: "Now explain this." at end of #8, and couldn't, so I tried to clarify what OP did. (the only thing I could think of to add was a `du junk`, to verify it was 9yyM [900+M], just before `rm junk`)

Edit: on the distro, OP mentions Ububtu 16.10 host; CentOS VBox guest here,
so 'all MY bets are off' IF this is being done IN guest! (Because I'm not sure what .vdi 'magic' happens [tho I play only in VBoxes].) I'll 'assume' it's the Ubuntu 'normal/real' host, tho.

Sorry for delay...

My OS is Ubuntu 16.10 with ext4 file system. I was trying to delete some folders in terminal, so I issued sudo rm -rf * command, which i thought i did, but actually it was sudo rm -rf /*. It took me around 2 seconds to realize the mistake, but by the time most of OS folder like /etc and my personal mounted partitions were gone.

I first tried to recover data by using testdisk tool (from systemrescuecd). Because I was using this tool for first time, and the interface was confusing I just gave-up. The data were mostly Linux distros ISOs and Virtualbox/KVM OS backups (VDIs) which were very old anyway.

So I unmounted all partitions, deleted all logical volumes, created new logical volumes and restored my old Fedora 25 OS clone which i had created using fsarchiver.

I tend to keep this hard disk till I by new one, and then I'll donate this disk to someone. @JeremyBoden, I'm donating not gifting....

So I tried to clean the free space (individual partitions) with zero using the DD command. And then, for curiosity, I ran extundelete to check. I also recovered so many things which were very old.

I will clean again with tools like zerofree as @r3sistance suggested, but was curious how do i prove myself that all data are gone. Of course I can run again extundelete, but is that only a way?

Thanks

Is there a difference?
And the disk, according to you, is on its last legs...

1 members found this post helpful.

Shred overwrites random data many times in an attempt to confuse forensic recovery techniques.

Using the retrospectoscope, it might be optimal to invert the data bit for bit, (i.e. 10101010 becomes 01010101) and leave it in that state for a while, THEN shred it.

Seriously man! I cant believe you are trolling me on this. You don't have this concept of donation.. isn't it? Heard of organizations who take your old computer junks, dissect them, take the good part, join them with other good parts of others, make them like real new, assemble them like real new and donate them to poor countries.

Buddy! just google how you can donate your old computer junks, there are lot of good private organizations who will come to your home and collect them.

If a disk is failing then, once any data is recovered from it, the best place for it is in the bin. The cost of repairing it, if in fact possible, is in most cases much more than of replacing it.

Donating it to an organization will only result in the wasted time of the volunteers who test the disk only to find it failing and, if it somehow gets past these tests, the probable and eventual loss of data in the computer of the person who receives it.

Knowing that a disk is failing and deciding to donate it is therefore pretty irresponsible, imo.

I give up.