Assertion failure in ext3_sync_file() at fs/ext3/fsync.c:50: "ext3_journal_current_handle() == 0"
adilger at clusterfs.com
Sun Nov 27 09:00:12 UTC 2005
On Nov 24, 2005 16:42 -0500, linux at horizon.com 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.
Principal Software Engineer
Cluster File Systems, Inc.
More information about the Ext3-users