Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My three partitions for my system are created with LVM on a LUKS partition (dm-crypt). These are /home, / and swap. The filesystem is ext4. They are encrypted, because they are on my laptop and I don't want that some laptop thieves get my data. But I often share my laptop with other people so they can access my encrypted partitions. I don't want that these people can recover my cache and all the data I deleted.

So I'm now trying to wipe all my free space on /home to prevent against recovering with tools like photorec. (one overwrite should do, the need of multiple overwriting is just a rumor) But still I haven't found any solution to wipe this free space successfully. I tried dd if=/dev/zero of=/home/fillitup bs=512 count=[count of free sectiors] so my partition was complete full of data. df /dev/mapper/home said 100% is used and there are 0 sectors available. But I could still recover gigs of data with photorec, although I selected to recover just form the free space. photorec displays: /dev/mapper/home - 340 GB / 317 GiB (RO) , but df displays that the size of /home is just 313G, why are there these differences and what did the 340GB means?

It looks like there is a place on my /dev/mapper/home partition, that I can't access to overwrite, but I can access it to recover. I also checked for corrupted sectors, but there aren't any. Maybe this is the space between my existing files?

Did anyone knows why I can't wipe my free space with dd, and how I can find the location of the loads of recoverable files, to securely delete them?

share|improve this question

migrated from Jun 23 '13 at 13:54

This question came from our site for professional and enthusiast programmers.

This isn't a programming question and belongs on Super User – LittleBobbyTables Jun 23 '13 at 12:10

Your method of filling all the free space up with zeros using dd should absolutely work.

Maybe it detected that you were writing zeros and it didn't actually write them (it made the file sparse). Try writing some other byte value instead?

dd if=/dev/zero bs=512 count=[count of free sectiors] | 
    tr \\000 \\001 >/home/fillitup

Regarding your parenthesized comment "one overwrite should do, the need of multiple overwriting is just a rumor", that isn't applicable anyway. The alleged insufficiency of one overwrite relates to physical recovery of data from the media. At that level your data are encrypted anyway, so even if they can recover bits from the media, those bits are encrypted.

share|improve this answer
I found the problem. The command "df" displays a wrong count of free sectors and this count of free sectors I uesed for dd. After I tried dd without the parameter "count" it worked. So df shows me that 140G are available, but with dd I could write 160G. If you use a floppy, than it is important to overwrite the data many times but on a lormal hard disk one overwriting sould do, look :… – peter4887 Jun 23 '13 at 23:19

Might consider using shred to attempt to destroy the large file you created. It will repeatedly overwrite the file.

If you are on a ssd, there are commands like fstrim to inform the underlying controller that the blocks are no longer in use and can be garbage collected (aka erased and ready for re-use).

Additionally, if you are on a device and working at a low-level, I know eMMC devices suport Secure Erase and Secure TRIM which will block until the blocks are fully erased and hence doesn't depend on the internal NAND controller to erase the blocks when it gets around to it.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .