Problem in e2fsck ? read error in journal inode

Erik Andersen Erik.Andersen at intecbilling.com
Sat Jan 6 10:47:52 UTC 2007


I understand the danger of not applying the journal, but I understand that what I will loose is
'only' the most recent changes in the filesystem.
Also I agree that the default behaviour of e2fsck should be to apply the journal if it exists,
No doubt about that.
But as e2fsck is ment as a tool for restoration of a damaged filesystem I expected it to be
able to bypass (or ignore) problems which prevents the action of the following parts.
My disk/partition has the problem (which seems like a hardware read-error) located in the 
inode where the journal is, so I cannot apply the journal, 
Because of this I would like to skip applying the journal and checking the inode used
for the journal. 
One way is, using debugfs, to set the appropriate attributes of the superblock so it looks 
like there is no journal (I thought it was the Filesystem Feature 'has_journal' which should 
not be set, but it seems that there are more attribute that needs fiddling..,).

Another way, was if there was an option to 'e2fsck' which made it ignore the journal (say '-ij'), 
it would let e2fsck read the superblock, but not attempt to do anything with the journal (including
reading the journal inode), e2fsck could then restore what it can.

/Erik Haukjaer Andersen


-----Original Message-----
From: Bruno Wolff III [mailto:bruno at wolff.to]
Sent: Sat 06-01-2007 05:06
To: Erik Andersen
Cc: ext3-users at redhat.com; tytso at mit.edu
Subject: Re: Problem in e2fsck ? read error in journal inode
 
On Fri, Jan 05, 2007 at 16:31:09 +0100,
  Erik Andersen <Erik.Andersen at intecbilling.com> wrote:
> 
> So my questios are:
> 1) How can I make e2fsck skip reading a faulty journal (in my case there might be a HW error on the block) ?
> 2) What makes e2fsck act on a journal (is it because journal inode is set) ?
> 3) Shouldn't e2fsck act on wether the filesystem features (and in case of no 'has_journal' just ignore
>    any journal information - of course it still need to make sure the inode used for the journal isn't
>    used by anybody else) ?

This is a safety feature to make sure you don't shoot yourself in the foot.
If you are willing to throw away the changes in the journal that haven't been
committed to the normal locations yet, then you should be able to make some
changes to the journal to make it look like it is empty. You might even be able
to get away with just writing over the bad block. However, you really should
make an image of this partition before doing any writes to it. I don't know
what changes to make to the journal to make it appear empty.
 
 
--
This e-mail and any attachments are confidential and may also be legally
privileged and/or copyright material of Intec Telecom Systems PLC (or its
affiliated companies). If you are not an intended or authorised recipient
of this e-mail or have received it in error, please delete it immediately
and notify the sender by e-mail. In such a case, reading, reproducing,
printing or further dissemination of this e-mail or its contents is strictly
prohibited and may be unlawful.
Intec Telecom Systems PLC does not represent or warrant that an attachment
hereto is free from computer viruses or other defects. The opinions
expressed in this e-mail and any attachments may be those of the author and
are not necessarily those of Intec Telecom Systems PLC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20070106/de1348e1/attachment.htm>


More information about the Ext3-users mailing list