On Nov 24, 2005 16:42 -0500, linux@xxxxxxxxxxx wrote: > ------------[ cut here ]------------ > kernel BUG at fs/ext3/fsync.c:50! > Process aptitude (pid: 26952, threadinfo=c13bc000 task=d99cca80) > Call Trace: > [<b01458ce>] msync_interval+0x8e/0xd0 > [<b0145a6f>] sys_msync+0x15f/0x171 > [<b0102c69>] syscall_call+0x7/0xb This BUG is: J_ASSERT(ext3_journal_current_handle() == 0); which means that somehow the aptitude process struct had a journal handle still active when it shouldn't have. Are there any console messages or before the BUG, or just ENOSPC from the program? Either way, I'd suspect a bug in the error handling code not doing a journal_stop() before exiting a function somewhere... > Here's the tune2fs -l output. No idea why it says "clean"; it is still > mounted read/write. > > Filesystem features: has_journal filetype needs_recovery sparse_super > Filesystem state: clean FYI - all ext3 filesystems say "clean" all the time, because when the journal replay is completed (note "needs_recovery" flag above) the filesystem will in fact be clean (i.e. not needing an e2fsck). If this were "error" (after the kernel detected some on-disk error) then you'd get a full e2fsck on boot regardless of ext3 recovery or not. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
