As far as I can tell, the only thing that gets zeroed
is the block pointers in the inode (i.e. 12 direct pointers
and one each of single, double and tripple indirects).
so, I'm presuming that all that should need to be
regenerated (and saved), above and beyond what is
already done, is the pointers in the inode itself, which
should take slightly less core than the whole inode entry.
I just did a restore of a 1.5GB tar file from ext3, and the
only information that I had to recover was the pointers
that were in the inode.
Identifying the triple indirect block (real easy) meant that I was only
missing 1MB+ of the file, and finding the double indirect (only slightly
harder) meant
that I was only missing another 48K.
Hunting that last 48K (12 blocks) out of the universe of unallocated blocks
was the real bitch of the recovery process.
If I had those 12 direct block pointers, I could have probably recoveed
the entire tar file in under an hour. and with the extra two pointers
(single and double and indirect) my time would have been down to 15 minutes
(mostly loading software and reading directions).
Theodore Tso wrote:
On Sun, Sep 24, 2006 at 10:55:10AM -0700, Stephen Samuel wrote:
.....
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
Yep, that's what would have to be done. 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. Consider that if a DVD iso image file is being
_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
