Messages in this thread | | | From | "David E. Weekly" <> | Subject | Ext2fs OOPS: 2. (Help!) | Date | Sat, 18 Mar 2000 11:22:26 -0800 |
| |
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/
| |