linux-mips
[Top] [All Lists]

Re: ext3 under MIPS?

To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: ext3 under MIPS?
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Date: Fri, 11 Apr 2003 08:47:56 +0200
In-reply-to: <3E95D16D.1671BA5A@ekner.info>
Mail-followup-to: Linux MIPS mailing list <linux-mips@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <3E954651.C7AECB90@ekner.info> <20030410154050.GI5242@lug-owl.de> <3E95D16D.1671BA5A@ekner.info>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4i
On Thu, 2003-04-10 22:17:49 +0200, Hartvig Ekner <hartvig@ekner.info>
wrote in message <3E95D16D.1671BA5A@ekner.info>:
> Jan-Benedict Glaw wrote:

[ext3 fs corruption after journal recovery]

> I can reproduce this anytime by just pushing the reset button and checking 
> the filesystem
> at reboot after ext3 recovery has run. However, if I just do regular fsck's 
> (without unclean
> shutdowns) nothing seems to be wrong. So I am pretty sure it is something 
> which

How do you invoce fsck?

> goes wrong in conjunction with the unclean shutdowns.

That's bad then:-(

> Is ext3 journal recovery really supposed to recover everything to a state 
> where fsck returns no
> errors, or is it potentially leaving non-fatal errors in the filesystem (e.g. 
> lost inodes which just

No. The concept is different.

Such a journal will log things like:

- File creation/deletion
- Owner/timestamp/access changes

These informations are restored during journal recovery. Most
filesystems do /not/ store the actual data you're writing to a file into
the journal. So, after you've issued a write() and presses the reset
button, the journal contains the new filesize, but by possibility
__not__ the data you've written to the file. So file size is okay, but
file content isn't. It's basically the job of the journal to keep your
filesystem intact, but not your data.

If you do this:

        - Boot with / mounted r/o
        - e2fsck -f /dev/your-root-device
        - Reset
        - Boot with / mounted r/w
        - Write something
        - Reset

You shouldn't see fsck failing (except it may replay the journal for
filesystems which hadn't been mounted on /).

If you see corruption here (ie. fsck finds problems after replaying the
journal), something is serverely broken.


> reduces capacity, but does not cause further corruption if the filesystem is 
> used) which will then
> be picked up by a later fsck when one has time to run it?

It should present you a f/s with no *known* problems. If corruption
(broken DMA transfers, ...) took place, this hasn't eventually logget
into the journal so this isn't recovered:-)

> What does the error "Inodes that were part of a corrupted orphan linked list 
> found." actually
> mean? Is this a fatal error, or a non-critical error along the lines I 
> described above (an error
> which does not get any worse if the filesystem is used)?

I think this basically means that fsck found files of a (destroyed)
directory. But for exact statements here, read e2fsck's sources...

> Is there anybody with ext3 up and running who would volunteer to do a couple 
> of unclean
> shutdowns and see if the recovery works without any fsck errors present 
> afterwards?

:-)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

Attachment: pgpcMC4aFqLIj.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>