Well, All I can say is that I just reconstructed most of
a 1.5GB file, by doing nothing more than hunting down
the double indirect block, and the trick seemed to work fine.
I can try and reconstruct a larger file, and see what
happens to it, but it empirically seems like zeroing
indirect blocks must, at most, be limited to severely
fragmented large files.
Even if that's the case, being able to reconstruct
_most_ file easily seems like a nice improvement over
the current situation, and would be easy to recognize
for non-sparse files.
I made some changes to dls, and wrote a perl program
to do the trick. I'll be releasing it in a while, once I get
the time to tidy it up a bit and document the work.
(probably next week).
Theodore Tso wrote:
On Mon, Sep 25, 2006 at 03:22:42PM -0700, Stephen Samuel wrote:
That surprises me, and I'm not sure that's always true, in particular
if the transaction touches so many block allocation bitmaps that the
unlink gets broken up into multiple transactions. In that case I
would think the indirect blocks might have to be partially cleared so
that the on-disk image is consistent if we crash in the middle of the
unlink. Still, I haven't crawled through the code in detail in a
while, and it's possible that we do the block_forget on indirect block
boundaries to avoid this.
But if it's just a matter of saving and restoring the inode fields,
yes, that would be a much simpler patch.
--
Stephen Samuel +1(778)861-7641 samnospam@xxxxxxxxxxx
http://www.bcgreen.com/
Powerful committed communication. Transformation touching
the jewel within each person and bringing it to light.
_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
