Retaining undelete data on ext3
tytso at mit.edu
Sun Oct 8 17:03:29 UTC 2006
On Sun, Oct 08, 2006 at 06:52:14PM +0200, Bodo Thiesen wrote:
> Theodore Tso <tytso at mit.edu> wrote:
> > The other caveat is that
> > storing all of the previously zeroed block pointers temporarily in
> > memory could take quite a bit of memory, especially if what is being
> > deleted is really big.
> Even Stephens idea doesn't need MBs of space. After freeing all blocks
> pointed to by an ind, that ind is unlinked in it's dind or in the inode
> whatever applies. In this moment, we can already restore it's contents.
> So the worst case for 8k blocks is to remember two ind blocks, two dind
> blocks and one tind block and the inode. That makes 41088 bytes. I don't
> agree this to be a problem ;)
Actually, you can't --- that's the problem. Until the changes are
committed, which means that the changes represented in the filesystem
are self-consistent and in a transaction which has been committed to
the journal, you can't start restoring the information in the indirect
You could if you forced transaction boundaries between every single
indirect block, but that would seriously degrade ext3's unlink
performance, and slow down any other filesystem activity that might be
happenning at the same time.
This is what makes the undelete problem so subtle. Doing in such a
way which is optimal for performance, and is preserves the journalling
guarantees, and yet still allows the undelete, is more complicated
than it first appears.
> But as I told: Ideas are not the problem. Time is the problem.
More information about the Ext3-users