lkml.org 
[lkml]   [2002]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [BK PATCH] Add ext3 indexed directory (htree) support
    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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