On Sun, Oct 08, 2006 at 06:52:14PM +0200, Bodo Thiesen wrote: > Theodore Tso <tytso@xxxxxxx> 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 block. 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. Yep, exactly. - Ted _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
