[PATCH] ext3: zero freed blocks

[Ron Yorston]

I've removed Cc: centos at centos.org, as I think we've probably outstayed
our welcome on that list.

Theodore Tso <tytso at mit.edu> wrote:
>Ideally, this wouldn't be done as a mount-time option, but rather only
>if the secure_delete flag is set on the file.  That way you don't do
>it for all files, but just those that need to be zeroed.

We can use both a mount option and the secure delete flag.  As Ted wrote
on a previous occasion this came up on LKML:

>The obvious thing to do would be to make it a mount option, so that
>(a) recompilation is not necessary in order to use the feature, and
>(b) the feature can be turned on or off on a per-filesystem feature.
>In 2.6, it's possible to specify certain mount option to be specifed
>by default on a per-filesystem basis (via a new field in the
>superblock).
>
>So if you do things that way, then secure deletion would take place
>either if the secure deletion flag is set (so it can be enabled on a
>per-file basis), or if the filesystem is mounted with the
>secure-deletion mount option. 

Personally I find a mount option much more useful than a per-file flag.

>The patch also has the potential danger that the data blocks are
>getting zeroed before the transaction which contains the unlink has
>committed.  There is therefore the risk that the system might crash
>after the blocks have been zero'ed, but before transaction has
>committed.  In that case, the file will still be there, but some or
>all of its contents will be zero'ed.  

Indeed, I was aware of this possibility, and breaking guarantees about
the atomicity of delete is a bad thing.  (Does ext2 provide any such
guarantee?)

The original patch (http://lwn.net/Articles/171924/) by Nikolai Joukov
had code to call ext3_journal_dirty_data on the data blocks, which may
have been intended to address this issue.  But I ripped it out because
it failed horribly when I tried to delete a file bigger than physical
RAM.

>The other thing which worries me about this patch is that if the
>blocks which you have zero'ed out get reallocated and used for some
>other file, and then data is written into the page cache and the page
>gets written to disk before the zero'ized buffers hit the disk, the
>new contents of the data blocks could get written.  The reason for
>this is that there is no cache coherency enforced between the page
>cache and buffer cache, and so it is necessary to be very careful when
>a particular block transitions between from being modified via buffer
>cache versus the page cache.

What are the consequences of this?  Is there any danger of the other
file being corrupted?  If not, and if our purpose is just to ensure that
the original contents of the freed blocks are destroyed, does it matter if
they're overwritten with something other than the zeroes we intended?

Ron