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

Re: another seriously corrupt ext3 -- pesky journal

On Thu, Aug 21, 2003 at 04:44:01PM -0400, Erez Zadok wrote:
> So if I understood it, we simply reserve double the space in the superblock
> to store this duplicate inode info.

The regular journal inode lives in the inode table.  The number of that
inode (typically 8) is recorded in the superblock.  The problem is that
the inode table can be very active, when, for example, the access times
change.  Since multiple inodes fit in a block, when one is dirty (e.g., the
one for /), the block needs to be rewritten.  As Ted pointed out, the
DMA engine will happily write crap to that block as the system is dying ...
But the data for that block of the inode table is already in the journal,
so if the journal survives, we can restore it.  By placing a copy 
of the inode data on infrequently written blocks (and in multiple copies)
e2fsck can find the journal inode contents and restore it to the inode
table, then proceed as usual.

> Is it
> correct that the journal inode info never changes? (no a/m/ctime, size
> changes, etc.)?

Mostly; see below.

> In that case, why not put a copy of this journal inode info in every copy of
> the superblock?  It's a one-time effort at mkfs time and have little to no
> impact at run time.  It costs a bit more space, but that's a small price to
> pay for increased reliability.

It is; note the word "all". ;-)

On Thu, Aug 21, 2003 at 12:04:21PM -0400, Theodore Ts'o wrote:
> +2003-08-21  Theodore Ts'o  <tytso mit edu>
> +
> +     * journal.c (e2fsck_move_ext3_journal): When moving the journal or
> +             backing up the journal inode, make sure it gets written to
> +             all the superblocks.
> +


	Bill Rugolsky

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