How to erase unused disk space?

[nostoc]

Hi!

Rather simple question which I have failed to find an answer to through googling:

How does one erase/shred unused disk space on fedora 17?

Thanks in advance.

[jpollard]

I assume you are talking about the available data space in a filesystem...

The simple answer is "you don't".

The problem is that it won't stay that way. This goes back to the subject of "object reuse".

The only way to do that even slightly efficiently is to do it when the block is released - Unfortunately, that will cause a major impact on performance as at a minimum it will add 5-10ms per block.

That is why you have to purge the file before you delete it. At that time you get to decide which blocks are to be purged.

Multiple overwrites is a slow process, and can't be optimized very well as doing so could leave the block "contaminated" until the purge is complete. It also adds a problem to recovery, as a purge has to be restartable (crash events) after reboot. You can't just replay a journal, as you have to purge the last released block, plus any others that haven't been purged.

The result is if you delete a large file (such as a video), you would take about 3 times as long as the time it took to copy the video in the first place. During that time, little other I/O would take place.

If you want to purge anyway, backup the data you want to keep, dismount the file system, and purge the partition. Then recreate the filesystem, mount and restore.

[stevea]

Originally Posted by jpollard

I assume you are talking about the available data space in a filesystem...

The simple answer is "you don't".

Sheesh - children of a lesser dog
Gotta love JP's "Can't do" attitude.



sudo yum -y install ucommon-bin
man zerofill
...
zerofill /mount/point/path

This uses a simple, tho' slow technique of creating a huge file (or files) that contain zeroes (or random data w/ the '-r' option), sync these files to disk, and then delete the files. The file(s) has thus allocated and filled all deallocated blocks.

You need to be root to get the reserved blocks.
If you point zerofill at a device - it will delete any filesystem on that device - be careful.

The problem is that it won't stay that way. This goes back to the subject of "object reuse".

OP never said he wanted a 'stay that way' feature.
He may just want to 'shred' currently de-allocated blocks.

The only way to do that even slightly efficiently is to do it when the block is released - Unfortunately, that will cause a major impact on performance as at a minimum it will add 5-10ms per block.

I've worked-on/developed systems for security models use where this was required. The performance hit would be nearly unnoticeable on a typical soho user system in normal use, unless you are deleting a lot of file-space..

That is why you have to purge the file before you delete it. At that time you get to decide which blocks are to be purged.

A/ No you don't. B/ No you can't, generally.

First it's hardware dependent. On SSDs for example you are allocated a new physical 'block' on every write. There is no way to 'purge' within the file system as a method to scrub physical data on the drive. There is often a secure erase at the hw level.

Next, there is no guarantee for an arbitrary file system that the block allocation is static when you overwrite, and it certainly IS NOT for btrfs and some others. Modern filesystems have features like COW and block de-duplication, snap-shotting, so writing zeroes to an allocated files block may simple allocate a different block for the zero'ing.

RAID-like features, checksums and COW, block de-duplication means that a block of file data does not directly correspond to a unique physical block contents. You'd better get your head out of the 1980s, it's not your grand-dads filesystem.

---------- Post added at 09:23 AM ---------- Previous post was at 09:06 AM ----------

Hmm - actually 'scrub' in the package of the same name has similar options as zerofill.
scrurb -X ...
Uses DoD 5220.22-M, scrubbing method.
Looks to be better supported than zerofill.

[jpollard]

And what I said is still true.

You don't scrub the free space.

You allocate it then scrub the file.

then delete it.

And it isn't guaranteed even then.

You are right about the SSDs, I should have included them.

And the only sure way for the others is to backup what you want, dismount then scrub the partition/disk.