[lkml]   [2000]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectExt2fs OOPS: 2. (Help!)
    Kernel Hackers,

    My apologies for posting this to the Linux Kernel list when I am not
    subscribed. I think you will quickly understand why this is so (for right
    now): I'm running qmail on my personal Linux server with mail delivery to
    Maildirs. I then use a patched version of the UW IMAP4.5 server that
    supports Maildirs. I had noticed that things had been getting *very* slow,
    i.e., opening a singular message taking over a minute. I checked in w/my
    server only to discover that imapd was hammering the system at 97% CPU
    usage -- but System CPU time, not User CPU time! I talked with the UW
    IMAP4.5 author and he explained that this was because ext2fs chokes pretty
    badly on very large directories due to its linear search algorithm.

    Then this morning, my machine, for the first time in months, died. Booting
    it back up and looking at the kernel log, I found something that I had last
    seen running Slackware about 4 and a half years ago: an Oops, seeming to
    originate from ext2fs (the stack trace shows that the machine was in the
    middle of the file system code).

    Here is the Oops:

    kmem_free: Bad obj addr (objp=c06b4f00, name=size-64)
    Unable to handle kernel NULL pointer dereference at virtual address
    current->tss.cr3 = 0128c000, %cr3 = 0128c000
    *pde = 00000000
    Oops: 0002
    CPU: 0
    EIP: 0010:[kfree+377/424]
    EFLAGS: 00010202
    eax: 00000039 ebx: c009e0e0 ecx: 00000002 edx: c2d54000
    esi: c06b4f00 edi: 00000202 ebp: 00000000 esp: c03e7ea0
    ds: 0018 es: 0018 ss: 0018
    Process imapd (pid: 24154, process nr: 72, stackpage=c03e7000)
    Stack: 00000000 000001f0 c06b4f5c c03f7ee0 c012f7bc c06b4f00 00000601
    c0200780 c0230240 c0130606 00000601 00000000 00000000 00000000
    00000601 00000000 c0230240 c0200780 c0230240 c0230238 c1efe228
    Call Trace: [prune_dcache+192/248] [try_to_free_inodes+34/52]
    2] [get_new_inode+189/284] [iget+88/96] [ext2_lookup+84/124]

    [lookup_dentry+294/496] [__namei+40/88] [sys_newstat+14/96]
    Code: c7 05 00 00 00 00 00 00 00 00 eb 1b 8d 76 00 56 68 82 18 1d

    Note the Call Trace. I tried running ksymoops on it, but the output did not
    look very useful. I will repost it here, anyhow, just in case it is useful
    to you all:

    Code; 00000000 Before first symbol
    00000000 <_EIP>:
    Code; 00000000 Before first symbol
    0: c7 05 00 00 00 00 00 movl $0x0,0x0
    Code; 00000007 Before first symbol
    7: 00 00 00
    Code; 0000000a Before first symbol
    a: eb 1b jmp 27 <_EIP+0x27> 00000027 Before
    first sy
    Code; 0000000c Before first symbol
    c: 8d 76 00 leal 0x0(%esi),%esi
    Code; 0000000f Before first symbol
    f: 56 pushl %esi
    Code; 00000010 Before first symbol
    10: 68 82 18 1d 00 pushl $0x1d1882

    I carefully set the and module directories to the right places
    (the /proc/ksyms and /proc/modules were just where they were expected) but
    this didn't look like a very useful output to humble 'ol me.

    So basically, ext2fs is dying hard on my honking big Maildir and I'm
    frustrated, because I had specifically converted to Mailbox for increased
    speed and efficiency over the mbox method of things (which created an
    understandably monolithic file that was also very, very slow to open and
    check through and additionally consumed massive amounts of memory as the
    WHOLE thing needed to be loaded into memory from disk and parsed every five
    minutes that my mail is rechecked. Aaah!). ALL I WANT TO DO IS BE ABLE TO

    [bangs head violently against table]

    If there's any more information I can provide the list with regarding the
    Oops (selected parts of the file, other things), I'd be happy to
    oblige. If anyone has a good solution for a software package that can allow
    for a server that can serve a *SINGLE USER* a lot of email efficiently, I'm
    all ears as well (I'm guessing that should probably be a personal
    correspondance, though).

    When are is Linux going to move to a modern, high-speed journalling

    Sorry for the long post.

    My Humble Regards to the Kernel Hackers,
    David E. Weekly

    PS: Please cc: on your reply.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

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