RE: Problem in e2fsck ? read error in journal inode

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

 



Title: RE: Problem in e2fsck ? read error in journal inode

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@xxxxxxxx]
Sent: Sat 06-01-2007 05:06
To: Erik Andersen
Cc: ext3-users@xxxxxxxxxx; tytso@xxxxxxx
Subject: Re: Problem in e2fsck ? read error in journal inode

On Fri, Jan 05, 2007 at 16:31:09 +0100,
  Erik Andersen <Erik.Andersen@xxxxxxxxxxxxxxxx> 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.
_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users

[Index of Archives]         [Linux RAID]     [Kernel Development]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Gimp]     [Yosemite News]

  Powered by Linux