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: Thu, 10 Apr 2003 17:40:50 +0200
In-reply-to: <3E954651.C7AECB90@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>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4i
On Thu, 2003-04-10 12:24:17 +0200, Hartvig Ekner <hartvig@ekner.info>
wrote in message <3E954651.C7AECB90@ekner.info>:
> Hi,
> 
> I have been using ext3 with MIPS, and it seems to work fine during normal 
> operations. However, when
> doing an unclean shutdown things don't exactly behave the way I believe they 
> should. Does anybody
> know how the ext3 recovery is supposed to work?
> 
> Basically I just reset the system mid-stream to see what happens. This means 
> the rc.sysinit "control
> file "/.autofsck" is on the filesystem to indicate an unclean shutdown. 
> During the next boot I get:
> 
> ... stuff deleted
> 
> ttyS02 at 0xb1300000 (irq = 2) is a 16550
> ttyS03 at 0xb1400000 (irq = 3) is a 16550
> EXT3-fs: INFO: recovery required on readonly filesystem.
> EXT3-fs: write access will be enabled during recovery.
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs: recovery complete.
> EXT3-fs: mounted filesystem with ordered data mode.

It recovers the journal. That's fine (and works as expected).

> VFS: Mounted root (ext3 filesystem) readonly.
> Freeing unused kernel memory: 64k freed
> Algorithmics/MIPS FPU Emulator v1.5
> INIT: version 2.84 booting
> 
> So, it seems the kernel ext3 filesystem code runs some kind of recovery based 
> on the
> journal prior to the actual mount of / occurring, which is exactly what I 
> would expect
> to happen, right?

Jupp.

> Then bootup continues with:
> 
> 
>                Welcome to Red Hat Linux
>                 Press 'I' to enter interactive startup.
> Mounting proc filesystem:  [  OK  ]
> Configuring kernel parameters:  [  OK  ]
> Cannot access the Hardware Clock via any known method.
> Use the --debug option to see the details of our search for an access method.
> Setting clock  (localtime): Thu Jan  1 01:00:13 CET 1970 [  OK  ]
> Activating swap partitions:  [  OK  ]
> Setting hostname copau01:  [  OK  ]
> modprobe: Can't open dependencies file /lib/modules/2.4.21-pre4/modules.dep 
> (No
> such file or directory)
> modprobe: Can't open dependencies file /lib/modules/2.4.21-pre4/modules.dep 
> (No
> such file or directory)
> Your system appears to have shut down uncleanly
> Press Y within 3 seconds to force file system integrity check...y
> Checking root filesystem
> /dev/hdc2: Inodes that were part of a corrupted orphan linked list found.
> 
> /dev/hdc2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
>         (i.e., without -a or -p options)
> [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -f /dev/hdc2
> 
> [FAILED]
> 
> *** An error occurred during the file system check.
> *** Dropping you to a shell; the system will reboot
> *** when you leave the shell.
> Give root password for maintenance
> (or type Control-D for normal startup):
> 
> So can somebody tell me what the heck just happened? After the ext3 recovery 
> done before the mount,
> .autofsck is still on the disk, so the rc.sysinit script of course assumes 
> the shutdown was unclean,

This ".autofsck" file seems to be a userland approach to detect a system
which wasn't shutted down completely. Even this is fine. What's *not*
okay is that there are still errors remaining. It seems your filesystem
has been damaged before (and in no means which could have been handled
by the journal).

> and pops the 5-second question. However, if I to be safe push "Y" here to get 
> my filesystem check (which
> I guess should be unnecessary, due to the ext3 recovery just run, right?), 
> strange things happen and
> fsck reports the "corrupted orphan list... " error.

Wrong. The journal should prevent you from actually loosing things at
hard-power-off situations. It does *not* cover things like silent data
corruption, which may have lead to this breakage.

> Is there something wrong here, or how should the system behave?

Everything with journal recovery is fine here. The failing fsck is a
different problem (a journal doesn't preven you to do a fsck at a
regular basis. It's only to not be forced to to it if you don't have the
time to do this *now* (on crash)).

So there seems do be some corruption (caused by whatever) going on at
your system:-(

Watch out if this happens again soon after you've completed the fsck.

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: pgpb4MwApw7pE.pgp
Description: PGP signature

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