Hi Jan, I've had three of these reports now within the past month. On Wed, Jan 16, 2002 at 01:39:44PM +0100, Branko F. Gračner wrote: > i'm using redhat 7.2 with ext3 as my primary fs on kernel 2.4.17 + > grsecurity + acl [ the others have been without any other patches on top of plain ext3] > Jan 16 12:37:37 frost kernel: Assertion failure in journal_start() at > transaction.c:225: "handle->h_transaction- > >t_journal == journal" Executive summary: during a delete, ext3 believes we end up writing a dquot entry out to the wrong filesystem. Does this ring any bells with you at all? In the mean time, I'm trying to reproduce it here. The assert failure is invariably followed by a call trace looking like sys_unlink vfs_unlink d_delete iput ext3_delete_inode ext3_mark_inode_dirty ext3_mark_iloc_dirty ext3_free_inode dquot_drop dqput write_dquot do_get_write_access generic_file_write __mark_inode_dirty do_get_write_access ext3_dirty_inode Translated, that means: we're doing an unlink; we start a transaction inside ext3_delete_inode; ext3 has already truncated the file back to zero, releasing all used data blocks; we have already marked the inode dirty (the ext3_mark_inode_dirty is just the remains of that call sitting on the stack); we have entered ext3_free_inode to release the inode itself; we have done the DQUOT_INIT(inode); DQUOT_FREE_INODE(inode); to update quota for the freed inode; we are trying to DQUOT_DROP(inode); to release the dquot struct and flush it to disk; dqput has called write_dquot to write the quota entry out; the generic_file_write into the quota file has tried to update the mtime and ctime timestamps; ext3_dirty_inode has been called to journal the timestamp update and has tried to start a new transaction; the journaling layer has BUG()ed because there is already a transaction open for the ext3_delete_inode (which is fine), but the new transaction is ON A DIFFERENT FILESYSTEM from the old one (which is really really bad news.) Cheers, Stephen
