lkml.org 
[lkml]   [2000]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectExt2fs OOPS: 2. (Help!)
Date
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
00000000
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
c0230240
c0200780 c0230240 c0130606 00000601 00000000 00000000 00000000
c013063e
00000601 00000000 c0230240 c0200780 c0230240 c0230238 c1efe228
c0230238
Call Trace: [prune_dcache+192/248] [try_to_free_inodes+34/52]
[grow_inodes+30/37
2] [get_new_inode+189/284] [iget+88/96] [ext2_lookup+84/124]
[real_lookup+74/112
[lookup_dentry+294/496] [__namei+40/88] [sys_newstat+14/96]
[system_call+
52/56]
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
mbol
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 System.map 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
READ MY EMAIL!

[bangs head violently against table]

If there's any more information I can provide the list with regarding the
Oops (selected parts of the System.map 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
filesystem?

Sorry for the long post.

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

PS: Please cc: dew@cs.stanford.edu on your reply.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2011 Jasper Spaans