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

Re: another seriously corrupt ext3 -- pesky journal

On Aug 23, 2003  09:58 -0400, Theodore Ts'o wrote:
> On Thu, Aug 21, 2003 at 02:47:06PM -0600, Andreas Dilger wrote:
> > Having only the inode i_blocks field duplicated in a backup inode means
> Correct.  Actually, what's being backed up is the i_block[] array as
> well as the i_size field.  It turns out that the i_blocks (number of
> blocks) field isn't needed by e2fsck, so I didn't bother backing it up.

Yeah, that's what I meant - i_block[] and not i_blocks (names too close ;-).

> > What would also be needed (not sure if this is implemented or not) is that
> > in the case of a corrupt superblock e2fsck assumes "needs_recovery" is set
> > if "has_journal" is set and the (backup) journal inode can be read, so that
> > the journal replay is actually done.  That will almost always result in the
> > primary superblock being restored from somewhere in the journal, along with
> > other useful things like bitmaps and such.
> Ooh, good point.  Yeah, I definitely need to do that, since if the
> primary superblock is trashed, the needs_recovery flag won't be set in
> the backup superblocks.  I need to think a bit to make sure there
> won't be any potential lossage cases caused by attempting to replay a
> journal when it's not necessary, but I don't think there are any.

I was a bit worried about it myself, but I think re-replaying the journal
will be safe, and the journal itself can detect if there is corruption
(except in the rare case of corruption between the transaction start and
commit blocks, but we would hit that regardless).

Even so, we wouldn't normally be "redoing" the journal replay, we would
just be giving it the chance to replay.  The journal itself will record
the last transaction that was flushed to the filesystem, so only newer
transactions will be replayed as it normally would be.

We can consider separately if e2fsck should try to "recover" corrupt
metadata blocks from the journal either by forcing a journal replay of
all transactions in the journal or by doing the metadata block recovery
one at a time from the journal on an as-needed basis (probably just
saving the physical block number in the journal with the logical block
that it represents when the journal is first loaded).

Cheers, Andreas
Andreas Dilger

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