public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Collins <bcollins@debian.org>
To: Andrew Morton <akpm@zip.com.au>, linux-kernel@vger.kernel.org
Subject: Re: Bug in ext3
Date: Thu, 15 Nov 2001 18:38:58 -0500	[thread overview]
Message-ID: <20011115183858.N329@visi.net> (raw)
In-Reply-To: <20011115092452.Z329@visi.net> <3BF3F9ED.17D55B35@zip.com.au>, <3BF3F9ED.17D55B35@zip.com.au> <20011115153442.A329@visi.net> <3BF42A1A.5AE96A78@zip.com.au> <20011115160232.H329@visi.net> <20011115145803.R5739@lynx.no> <20011115170628.J329@visi.net> <20011115162149.U5739@lynx.no>
In-Reply-To: <20011115162149.U5739@lynx.no>

On Thu, Nov 15, 2001 at 04:21:49PM -0700, Andreas Dilger wrote:
> On Nov 15, 2001  17:06 -0500, Ben Collins wrote:
> > On Thu, Nov 15, 2001 at 02:58:03PM -0700, Andreas Dilger wrote:
> > > Please run e2fsck (1.25) to clear this up.  It may be that you have other
> > > corruption in your filesystem.  If you are sure you _never_ tried ext3
> > > on this filesystem before, yet the has_journal bit is set, this could
> > > be an indication of memory or cable problems.
> > 
> > Uh, something corrupted it. Believe me, there is no other corruption.
> > I've reverted to a non-ext3 kernel, and after a day of serious IO, no
> > problems have shown. So something is wrong, and it isn't my filesystem
> > (the erroneous flag needs to be cleared, yes, but the fact remains that
> > there is a problem in this case).
> 
> I don't disagree that something corrupted it, but it is hard to tell from
> here what it could be.  Looking at ext3_read_super(), it is pretty much
> a read-only path, except journal recovery.  If, for some reason, you had
> an old, unrecovered ext3 journal in the fs, it is possible that recovering
> from it would corrupt your fs by writing old data into the fs.
> 
> This _shouldn't_ happen with newer kernels, but with old 2.2 ext3 code
> this was a possibility.  Also, with old e2fsck code (1.18 was right at the
> very beginning when ext3 support was being added) it is possible that it
> didn't fail because of the has_journal flag, but it wasn't smart enough
> to detect and remove an old corrupt journal.  I'm not saying this is a
> likely scenario either, but we don't have much to go on.

I wont say that I am absolutely 100% sure that ext3 was never tried on
this filesystem. I am pretty certain, but I'm guessing it doesn't really
make much difference at this point. Your scenario of the corruption
makes sense. I'll see if I can test your patch at some point (but I most
likely cannot).

Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          <none>
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype sparse_super
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1015808
Block count:              2028288
Reserved block count:     101414
Free blocks:              368490
Free inodes:              688732
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Last mount time:          Thu Nov 15 10:07:12 2001
Last write time:          Thu Nov 15 18:29:55 2001
Mount count:              2
Maximum mount count:      20
Last checked:             Thu Nov 15 08:48:40 2001
Check interval:           15552000 (6 months)
Next check after:         Tue May 14 09:48:40 2002
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal UUID:             <none>
Journal inode:            48
Journal device:           0x0000
First orphan inode:       0


-- 
 .----------=======-=-======-=========-----------=====------------=-=-----.
/                   Ben Collins    --    Debian GNU/Linux                  \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

  reply	other threads:[~2001-11-15 23:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-15 14:24 Bug in ext3 Ben Collins
2001-11-15 17:22 ` Andrew Morton
2001-11-15 20:34   ` Ben Collins
2001-11-15 20:48     ` Andrew Morton
2001-11-15 21:02       ` Ben Collins
2001-11-15 21:10         ` Andrew Morton
2001-11-15 22:04           ` Ben Collins
2001-11-15 21:58         ` Andreas Dilger
2001-11-15 22:06           ` Ben Collins
2001-11-15 22:49             ` Mike Fedyk
2001-11-15 22:58               ` Ben Collins
2001-11-15 23:21             ` Andreas Dilger
2001-11-15 23:38               ` Ben Collins [this message]
2001-11-16  0:07                 ` Andreas Dilger
2001-11-16  0:55                   ` Ben Collins
2001-11-16  3:09                     ` Andreas Dilger
2001-11-16  3:20                       ` Ben Collins
2001-11-16  3:37                         ` Mike Fedyk
2001-11-16  4:50                         ` Andreas Dilger
2001-11-16 18:38               ` Stephen C. Tweedie
2001-11-16 18:44                 ` Stephen C. Tweedie
2001-11-16 14:52         ` Stephen C. Tweedie

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=20011115183858.N329@visi.net \
    --to=bcollins@debian.org \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox