I haven't read the code so I admit this is supposition. It sounds like the fix here is to try journal pointers and use the first pointer that doesn't result in an error. This means that if the first pointer is broken, you will check backup pointers until you find one that works and then use that. At this point you haven't checked that this is the *right* journal but at least you're not blindly just using a pointer. Thinking of Sun's Disksuite metadata databases, I'm wondering if it would make sense (only at startup) to test all the pointers, toss the ones that are invalid and then use the majority value. And is anyone working on a journal repair or editing utility? Dana Bourgeois > -----Original Message----- > From: ext3-users-admin@xxxxxxxxxx > [mailto:ext3-users-admin@xxxxxxxxxx] On Behalf Of Bill Rugolsky Jr. > Sent: Thursday, August 21, 2003 1:25 PM > To: Erez Zadok > Cc: ext3-users@xxxxxxxxxx > Subject: Re: another seriously corrupt ext3 -- pesky journal > > > On Thu, Aug 21, 2003 at 03:28:03PM -0400, Erez Zadok wrote: > > How does the kernel know to write the journal data first to > some data > > block belonging to inode X, and then to another data block > of inode Y? > > Both X and Y are journal inodes, right? Will there be a > reserved inum > > other than 8, for the backup journal? > > > > Is there some magic in which the kernel can identify any number of > > special journal inodes? > > > > And while we're at it, why only one backup journal inode? Why not > > several? If it's good enough to have several copies of superblocks > > etc., then why not the journal (for those willing to pay the > > performance penalty)? > > Erez, > > If I understand Ted correctly, the contents of the journal > inode, not the contents of the journal, are replicated. In > particular, there is a copy of the block pointers that > specify where the journal is located. The JBD code takes > care of ensuring that the data in the journal is not garbage. > The problem is when the journal block pointers (i.e., the > journal meta-data) that identify where the journal lives > (since it is just a file, identified by a list of block > pointers) get corrupted. > > Regards, > > Bill Rugolsky > > > _______________________________________________ > > Ext3-users@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/ext3-> users > _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
