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 http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
