[PATCH] ext3: zero freed blocks

[Theodore Tso]

On Sat, Sep 09, 2006 at 11:36:27AM +0100, Ron Yorston wrote:
> >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?
> 

Yes, that's precisely what I'm worried about.  Specifically, if you
have this sequence of events:

1) File gets deleted; the file contents get zero'ed out via the the
buffer cache.  Since process of zeroing the files happen in the
background, for a large file, this could continue for a long time...

2) In the meantime, one or more of the disk blocks that was used by
the old file are reallocated for a new file.  The application writes
data to the new file, which is stored in the page cache.

3) The application calls fsync() and the contents of the new file are
flushed from the page cache and written to disk.

4) The dirty buffers containing the zero'ed out contents of the block
are written to disk, overwriting the contents of the new file.

5) Data is lost.

One way of solving this problem is to zero the blocks in the
foreground, and not allow the unlink to proceed until the data blocks
are overwritten.  Another way of solving the problem would be to not
allow those data blocks to be allocated until the zeroization buffers
have been written out.  Yet another way would be try to determine if
there is an outstanding buffer cache write from an attempt to zero the
free blocks, and abort the buffer cache write before doing the page
writeout.  That last would not be trivial, and would require violating
a number of abstraction boundaries...

Another question is to ask is whether or not you care that the freed
blocks might not be zero'ed if the system crashes before the buffer
cache is written out.  Currently, there is a chance that after a
system crash some deleted file blocks won't be zero'ed.  Depending on
your requirements, that might or might not be fatal, though.  

						- Ted