All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: ext3 under MIPS?
Date: Thu, 10 Apr 2003 17:40:50 +0200	[thread overview]
Message-ID: <20030410154050.GI5242@lug-owl.de> (raw)
In-Reply-To: <3E954651.C7AECB90@ekner.info>

[-- Attachment #1: Type: text/plain, Size: 4560 bytes --]

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 #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2003-04-10 15:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-10 10:24 ext3 under MIPS? Hartvig Ekner
2003-04-10 15:40 ` Jan-Benedict Glaw [this message]
2003-04-10 20:17   ` Hartvig Ekner
2003-04-11  6:47     ` Jan-Benedict Glaw
2003-04-11 10:05       ` Hartvig Ekner
2003-04-11 10:17         ` Brian Murphy
2003-04-11 13:35         ` Karsten Merker
2003-04-11  7:50     ` Brian Murphy
2003-04-11  8:28       ` Kevin D. Kissell
2003-04-11  8:28         ` Kevin D. Kissell
2003-04-11  8:25         ` Brian Murphy
2003-04-11 13:36         ` Karsten Merker
2003-04-10 17:20 ` Karsten Merker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030410154050.GI5242@lug-owl.de \
    --to=jbglaw@lug-owl.de \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.