Retaining undelete data on ext3

[Andreas Dilger]

On Sep 24, 2006  10:55 -0700, Stephen Samuel wrote:
> Having just spent a day trying to recover a deleted ext3 file
> for a friend, I'm wondering about this way of maintining
> undelete information in ext3, like is done for ext2:
> 
> The last step in the deletion process would be to put back
> the (previously zeroed) block pointers.  Since it gets logged
> to the journal, I _think_ that this should be safe.  The worst
> that would happen is that, if the plug gets pulled in the
> middle of a file delete, the old block pointers would be
> unavailable --  I don't see this as a killer issue, since
> editing the filesystem to do an undelete should be considered an
> emergency operation anyways.

I've written a couple of times the best way to do this, while improving
unlink/truncate performance at the same time (see last sentence):

        "It would be possible to walk the inode and precompute the number
	of bitmaps and group descriptors that would be modified by the
	operation and try to start a single transaction of that size.  If
	this transaction can be started (true in most cases), then we are no
        longer required to zero out all of the [dt]indirect blocks (as we
        do not have to worry about restarting the operation) and we only
        have to update the block bitmaps and their group summaries, reducing
        the amount of IO considerably for block-mapped files.  Also, the
        walking of the file metadata blocks can be done in forward order
        and also asynchronous readahead can be started for indirect blocks
        to make more efficient use of the disk.  As an added benefit we
        would regain the ability to undelete files in ext3 because we no
        longer have to zero out all of the metadata blocks."

The only issue is that nobody has worked on implementing this yet, and I
don't have time.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.