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@xxxxxxx> > + > + * 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. > + Regards, Bill Rugolsky _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
