search for: journal_forget

Hello ext3-users, I tested ext3 on a Linux for S/390 with several stress and benchmark test tests and faced a kernel bug message. The console showed the following output: Message from syslogd@boeaet34 at Fri Aug 3 11:34:16 2001 ... boeaet34 kernel: Assertion failure in journal_forget() at transaction.c:1184: "! jh->b_committed_data" I tried the Patch from http://www.zip.com.au/~akpm/ext3-2.4-0.9.5-247.gz with the kernel 2.4.7 with a new LVM- patch(0.9.1) and some S/390 specific patches. I use mke2fs version 1.22. S/390 is a 32bit big endian machine. After compili...

Just to make sure somebody reacts (please) I'm forwarding this. Please cc me on replies as I'm not subscribed to this list. -------- Original Message -------- Subject: [RESEND] 2.4.20: ext3: Assertion failure in journal_forget()/Oops on another system Date: Wed, 04 Dec 2002 21:27:31 +0100 From: Andreas Steinmetz <ast@domdv.de> To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, sct@redhat.com, akpm@zip.com.au, adilger@clusterfs.com It seems that either my previous post (below) was to vague or it...

...The night after I booted with the older kernel, the machine had the following in its logs. It must have been when trying to delete some older archives. Mar 30 02:37:11 musicien kernel: invalid operand: 0000 Mar 30 02:37:11 musicien kernel: CPU: 0 Mar 30 02:37:11 musicien kernel: EIP: 0010:[journal_forget+170/400] Not tainted Mar 30 02:37:11 musicien kernel: EFLAGS: 00010286 Mar 30 02:37:11 musicien kernel: eax: 00000058 ebx: c3f29ab0 ecx: c1760000 edx: c5e96a20 Mar 30 02:37:11 musicien kernel: esi: c5fc7e00 edi: c3e55a40 ebp: c41be6a0 esp: c1761d2c Mar 30 02:37:11 musicien kernel: ds...

...ertion failure from SnapFS, at ext3_new_block() in fs/ext3/balloc.c: J_ASSERT (!test_and_set_bit(BH_Alloced, &bh->b_state)) If J_ASSERT is only use as debug, why it will modify data? I found the 'BH_Alloced' flag only occures at two place: one is balloc.c as above, the other is at journal_forget() in fs/jfs/transaction.c: J_ASSERT (!test_and_set_bit(BH_Freed, &bh->b_state)); clear_bit(BH_Alloced, &bh->b_state); here after assert, we clear the bit right away. So the other question is: If one block was new alloced, BH_Alloced was set in it's buffer_header and there is no...

...:40 boeaet34 kernel: <n.cl_dead 1d8c2f50 Aug 9 17:57:40 boeaet34 kernel: nsaction.c, 96): start_this_handle: New handle 1e701180 going live. Aug 9 17:57:41 boeaet34 kernel: sa Aug 9 17:57:41 boeaet34 kernel: <7ead 1da28bc0, force_copy 1 Aug 9 17:57:41 boeaet34 kernel: Assertion failure in journal_forget() at transaction.c:1184: "!jh->b_committed_data" Aug 9 17:57:41 boeaet34 kernel: kernel BUG at transaction.c:1184! Aug 9 17:57:41 boeaet34 kernel: illegal operation: 0001 Aug 9 17:57:41 boeaet34 kernel: CPU: 0 Aug 9 17:57:41 boeaet34 kernel: Process rm (pid: 534, stackpage=1DA59...

.../27 03:57 pm>ext3: Unknown symbol journal_dirty_data <Jun/27 03:57 pm>ext3: Unknown symbol journal_force_commit_nested <Jun/27 03:57 pm>ext3: Unknown symbol journal_init_dev <Jun/27 03:57 pm>ext3: Unknown symbol journal_dirty_metadata <Jun/27 03:57 pm>ext3: Unknown symbol journal_forget <Jun/27 03:57 pm>ext3: Unknown symbol journal_wipe <Jun/27 03:57 pm>ext3: Unknown symbol journal_blocks_per_page <Jun/27 03:57 pm>ext3: Unknown symbol journal_blocks_per_page <Jun/27 03:57 pm>ext3: Unknown symbol journal_errno <Jun/27 03:57 pm>ext3: Unknown symbol jour...

...ee_blocks: Freeing blocks not in datazone - block = 1566266724, count = 1 EXT3-fs error (device sd(8,49)): ext3_free_blocks: Freeing blocks not in datazone - block = 1291668583, count = 1 EXT3-fs warning (device sd(8,49)): ext3_free_blocks: bit already cleared for block 2213 Assertion failure in journal_forget() at transaction.c line 860: "!test_and_set_bit(BH_Freed, &bh->b_state)" Unable to handle kernel NULL pointer dereference at virtual address 00000000 current->tss.cr3 = 00101000, %cr3 = 00101000 *pde = 00000000 Oops: 0002 CPU: 0EXT3-fs warning (device sd(8,49)): ext3_free_bl...

Having just spent a day trying to recover a deleted ext3 file for a friend, I'm wondering about this way of maintining undelete information in ext3, like is done for ext2: The last step in the deletion process would be to put back the (previously zeroed) block pointers. Since it gets logged to the journal, I _think_ that this should be safe. The worst that would happen is that, if the plug