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.
_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
