linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Ryan Cumming <ryan@completely.kicks-ass.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BK PATCH] Add ext3 indexed directory (htree) support
Date: Thu, 26 Sep 2002 18:04:32 -0400	[thread overview]
Message-ID: <20020926220432.GB10551@think.thunk.org> (raw)
In-Reply-To: <200209261208.59020.ryan@completely.kicks-ass.org>

On Thu, Sep 26, 2002 at 12:08:54PM -0700, Ryan Cumming wrote:
> On September 26, 2002 08:42, Theodore Ts'o wrote:
> > Hmm... I just tried biult 2.4.19 with the ext3 patch on my UP P3
> > machine, using GCC 3.2, and I wasn't able to replicate your problem.
> > (This was using Debian's gcc 3.2.1-0pre2 release from testing.)
> The whole GCC 3.2 thing was a red herring. Although it ran stable for a few 
> hours last night (cvs up, compiled a kernel, etc), the filesystem was once 
> again read-only when I came to check my mail this morning.

Was there anything in the logs at all?  There should be, if the
filesystem was remounted read-only.

> The interesting fsck errors this time were:
> 245782 was part of the orphaned inode list FIXED
> 245792 was part of the orphaned inode list FIXED
> 245797...
> 
> 245782,245792 don't exist according to ncheck.

That's not surprising. What this means is that those inodes were
deleted, but since some process still had a file descriptor open for
that inode, it was placed on the orphaned inode list.  But the
directory entry would have already been removed, which is why ncheck
couldn't find an associated pathname.  The e2fsck error message simply
states that these inodes had a dtime which was small enough that it
was probably the next entry on the orphaned inode linked list, these
inodes weren't actually on the list.  At a guess, this probably
happened when an error was noted in the filesystem, and the filesystem
was forcibly put into the read-only state.  That probably arrested
some transactions which were not fully completed, and would explain
these sorts of fsck errors.

The real question is what was the original error that caused the ext3
filesystme to decide it needed to remount the filesystem read-only.
That should be in your logs, since calls to ext3_error should always
cause printk's explaining what the error was to be sent to the logs.

The filesystem wouldn't happen to be running close to full either on
the number of blocks or the number of inodes, would it?  There's a bug
in ext3 (for which Stephen has already posted bug fixes to be applied
to the 2.4.20-preX kernels) where an running out of blocks or inodes
is being erroneously flagged as a filesystem corruption error, which
would mount the filesystem read-only.

						- Ted

  parent reply	other threads:[~2002-09-26 22:00 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-25 20:03 tytso
2002-09-25 20:34 ` Andreas Dilger
2002-09-25 20:41 ` Dave Jones
2002-09-25 21:08   ` Andreas Dilger
2002-09-25 21:34   ` Theodore Ts'o
2002-09-25 22:54 ` Jeff Garzik
2002-09-25 23:29   ` Theodore Ts'o
2002-09-25 23:45     ` Ryan Cumming
2002-09-26  3:27       ` Theodore Ts'o
2002-09-26  5:23         ` Ryan Cumming
2002-09-26  5:57           ` Theodore Ts'o
2002-09-26  6:22             ` Ryan Cumming
2002-09-26 14:05               ` Theodore Ts'o
2002-09-26  6:25             ` Ryan Cumming
2002-09-26 11:25               ` Daniel Egger
2002-09-26  7:41             ` Ryan Cumming
2002-09-26 13:23               ` Theodore Ts'o
2002-09-26 15:42               ` Theodore Ts'o
2002-09-26 19:08                 ` Ryan Cumming
2002-09-26 19:51                   ` Horst von Brand
2002-09-26 19:59                     ` Ryan Cumming
2002-09-26 22:04                   ` Theodore Ts'o [this message]
2002-09-26 22:53                     ` Ryan Cumming
2002-09-26 23:57                       ` Theodore Ts'o
2002-09-27  1:00                         ` Ryan Cumming
2002-09-27  3:24                           ` Theodore Ts'o
2002-09-27  4:12                         ` Andreas Dilger
2002-09-27  7:55                           ` Ryan Cumming
2002-09-28  1:20                           ` Ryan Cumming
2002-09-28  1:46                             ` Ryan Cumming
2002-09-28 14:13                             ` Theodore Ts'o
2002-09-28 14:18                               ` Theodore Ts'o
2002-09-28 22:35                                 ` Ryan Cumming
2002-09-28 17:27                               ` [Ext2-devel] " Andreas Dilger
2002-09-28 18:43                                 ` chrisl
2002-09-28 19:45                                 ` chrisl
2002-09-28 22:30                               ` Ryan Cumming
2002-09-29  7:03                               ` [PATCH] fix htree dir corrupt after fsck -fD chrisl
2002-09-29  8:16                                 ` Ryan Cumming
2002-09-29  8:36                                   ` Ryan Cumming
2002-09-30  2:46                                   ` Ryan Cumming
2002-09-29 14:13                                 ` Theodore Ts'o
2002-09-25 23:31 ` [BK PATCH] Add ext3 indexed directory (htree) support Daniel Egger
2002-09-26  0:32   ` Randy.Dunlap
2002-09-26  0:50 ` Aaron Lehmann
2002-09-26  3:28   ` Theodore Ts'o
2002-10-02  9:11 tytso

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=20020926220432.GB10551@think.thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ryan@completely.kicks-ass.org \
    --subject='Re: [BK PATCH] Add ext3 indexed directory (htree) support' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).