[lkml]   [2001]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Bug in ext3
    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 \
    ` -- -- '
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:13    [W:0.044 / U:33.160 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site