[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: data recovery openoffice.sx? on ext3-partition

On Sep 04, 2002  13:45 +0100, Stephen C. Tweedie wrote:
> Truncate transactions (like the ones implicit in delete) can get
> _really_ large.  The filesystem has bounds on the size of a
> transaction, but there are essentially no bounds on the amount of
> metadata a truncate can modify.  So to fit things into the limited
> space in the journal, ext3 needs to be able to split a truncate over
> multiple transactions.
> And that is not possible unless we record, on disk, the incremental
> progress of each bit of the truncate.  If we didn't record progress,
> then if we crashed in the middle of the truncate, the metadata on disk
> would be in a mess, and ext3 is supposed to prevent that!
> But a side-effect of keeping the on-disk progress of the truncate
> coherent is that once the truncate completes, all record of the
> original data has been wiped out.

I was thinking about this recently.  For the most common
truncate-to-zero operation (i.e. before unlink) there need only be
a limited number of blocks modified - the inode block, the superblock
(for free block counts), and at most 2 blocks for each group for which
this inode has blocks allocated (block bitmap and group descriptor,
although many groups will share a descriptor block).

We do not actually need to write out any of the {t,d,}indirect blocks
if we either zap the block pointers in the inode (which doesn't get
us very far ahead), or simply do as ext2 does and mark the inode as
unused in the inode bitmap and with nlinks = 0.

If desired, we could still do this operation in 2 stages:
1) mark inode unused in inode bitmap and nlinks = 0, put it on orphan list
2) update all of the block bitmaps and group descriptor summaries

If we crash between 1 & 2, we can always restart 2 like we do now.
I believe we would need a "shadow" in-memory inode bitmap so we don't
re-allocate this inode until the truncate is completed, like we do
for the block bitmaps already.

Cheers, Andreas
Andreas Dilger

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]