search for: h_buffer_credits

While ripping one of my cds on my laptop this happened: Message from syslogd@theirongiant at Thu Jul 5 09:52:16 2001 ... theirongiant kernel: Assertion failure in do_get_write_access() at transaction.c line 551: "handle->h_buffer_credits > 0" from the kern.log: Assertion failure in do_get_write_access() at transaction.c line 551: "handle->h_buffer_credits > 0" Unable to handle kernel NULL pointer dereference at virtual address 00000000 current->tss.cr3 = 0a2e8000, %%cr3 = 0a2e8000 *pde = 00000000 Oops:...

This version fixes three bugs in the 2nd patch of this series that caused kernel BUG when the system was under race. We weren't accounting with t_oustanding_credits correctly, and there were race conditions caused by the fact the I had overlooked the fact that __jbd2_log_wait_for_space() and jbd2_get_transaction() requires j_state_lock to be write locked. Theodore Ts'o (3): jbd2: Use

The ocfs2 directory index updates two blocks when we remove an entry - the dx root and the dx leaf. OCFS2_DELETE_INODE_CREDITS was only accounting for the dx leaf. This shows up when ocfs2_delete_inode() runs out of credits in jbd2_journal_dirty_metadata() at "J_ASSERT_JH(jh, handle->h_buffer_credits > 0);". The test that caught this was running dirop_file_racer from the ocfs2-test suite with a 250-character filename PREFIX. Run on a 512B blocksize, it forces the orphan dir index to grow large enough to trigger. Signed-off-by: Joel Becker <joel.becker at oracle.com> --- fs/ocf...

...help > I have late last year converted all my machines to ext3 no problems > now I have one machine crashing once every 4 / 5 days > I have used a crash dump and see the following > > <0>Assertion failure in do_get_write_access() at transaction.c:589: > "handle->h_buffer_credits > 0" > > Search on this seems to indicate the problem maybe with ext3 journaling > system > > I'm considering upgrading to 2.4.20 I'm using 2.4.19 currently > but my reading indicates that this will not solve the problem > and may make it worst > > The...

Fix "h_buffer_credits<0" assert failure during truncate. The bug occurs when the "i_blocks" count in the file's inode overflows past 2^31. That works fine most of the time, because i_blocks is an unsigned long, and should go up to 2^32; but there's a place in truncate where ext3 calculates th...

...le or superblock) I tried to 'cd' into a directory within that mount, and got this: EXT3 FS 2.4-0.9.16, 02 Dec 2001 on loop(7,0), internal journal EXT3-fs: mounted filesystem with ordered data mode. Assertion failure in do_get_write_access() at fs/jbd/transaction.c:746: "handle- >h_buffer_credits > 0" ------------[ cut here ]------------ kernel BUG at fs/jbd/transaction.c:746! invalid operand: 0000 CPU: 0 EIP: 0060:[<c01722f7>] Not tainted EFLAGS: 00010202 EIP is at do_get_write_access+0x3f3/0x530 eax: 0000006a ebx: c909c000 ecx: c13bcc80 edx: c02f1570 esi: c952...

...(few seconds after the above): attempt to access beyond end of device 03:06: rw=0, want=274736132, limit=55167178 EXT3-fs error (device ide0(3,6)): ext3_free_branches: Read failure, inode=10092558, block=-1541928704 Assertion failure in do_get_write_access() at transaction.c:708: "handle->h_buffer_credits > 0" invalid operand: 0000 CPU: 0 EIP: 0010:[<c0156fb7>] Not tainted EFLAGS: 00010286 eax: 00000063 ebx: c57dd430 ecx: ccf36780 edx: ffffffff esi: 00000000 edi: c57dd430 ebp: 00000000 esp: c5c6bcd0 ds: 0018 es: 0018 ss: 0018 Process videoexe (pid: 984, stackpa...

...cleared for block 9126180] <snip> Fri 13/12/02 23:56:00.242 [KMSG:<2>EXT3-fs error (device ide1(22,5)): ext3_free_blocks: Freeing blocks not in datazone - block = 3305048842, count = 1] [KMSG:<0>Assertion failure in do_get_write_access() at transaction.c:589: "handle->h_buffer_credits > 0"] [KMSG:<4>invalid operand: 0000] [KMSG:<4>CPU: 0] [KMSG:<4>EIP: 0010:[<c0156d09>] Not tainted] [KMSG:<4>EFLAGS: 00010286] [KMSG:<4>eax: 00000063 ebx: cefb4ac0 ecx: c55ac3c0 edx: fffffffe] [KMSG:<4>esi: c7083f00 edi: 00000002...

http://www.sample.banga.lt/crash.gif System - fully (except kernel) updated RedHat 7.3. Filesystems - ext3 in default ordered mode. What could be the cause of the crash? Kernel update will solve the problem? Thanks, Mindaugas

...er to clients > which puts it under abit of load but not a lot really > the machine has a 1 Gb processor and 768 Mb RAM so is reasonably > powerful. Below is the oops and extracted stack trace: <0>Assertion failure in do_get_write_access() at transaction.c:589: "handle->h_buffer_credits > 0" <4>invalid operand: 0000 <4>CPU: 0 <4>EIP: 0010:[<c015fb48>] Not tainted <4>EFLAGS: 00010286 <4>eax: 00000063 ebx: ead2ae20 ecx: ffffffff edx: 00000001 <4>esi: c1c7bae0 edi: c1c7bae0 ebp: c1c24000 es...

Hi, I'm running stock kernel 2.4.18, and was downloading some things when I filled up one of my partitions. This was sent to all attached terminals: Assertion failure in do_get_write_access() at transaction.c:708: "handle->h_buffer_credits > 0" I think: invalid operand: 0000 may have followed. Anyway, it also gave a stack trace and register dump (to syslog), which I've run through ksymoops specifying the map and vmlinux executable; the output is attached. The program that filled up the hard disk died (not sure if that&...

...*el; + struct ocfs2_extent_rec *rec; + + path = ocfs2_new_path_from_et(et); + if (!path) { + status = -ENOMEM; + return status; + } + + status = ocfs2_find_path(inode, path, new_end); + if (status < 0) { + mlog_errno(status); + goto out; + } + + status = ocfs2_extend_trans(handle, handle->h_buffer_credits + + path_num_items(path)); + if (status < 0) { + mlog_errno(status); + goto out; + } + + status = ocfs2_et_root_journal_access(handle, inode, et, + OCFS2_JOURNAL_ACCESS_WRITE); + if (status < 0) { + mlog_errno(status); + goto out; + } + + /* Change all the branch except t...

...ransaction + * doesn't reserve the credits for them either. + * + * But we do have a special case here which will update the rightmost + * records for all the bh in the path. + * So we have to allocate extra credits and access them. + */ + ret = ocfs2_extend_trans(handle, + handle->h_buffer_credits + subtree_index); + if (ret) { + mlog_errno(ret); + goto out; + } + + ret = ocfs2_journal_access_path(et->et_ci, handle, path); + if (ret) { + mlog_errno(ret); + goto out; + } + /* Path should always be rightmost. */ eb = (struct ocfs2_extent_block *)path_leaf_bh(path)->b_data; BUG_...

The old extent merging code down underneath "ocfs2_mark_extent_written()" can't merge extents between leaf blocks. This patch resolve this. So that a large unwritten extent which has been split up with a bunch of writes can be merged together once all unwritten regions have been written to. Modification from V1 to V2: 1. Add more comments for some functions which is more complicated

....2 kernel 2.6.18-92.el5.ppc64 We have Oracle RAC on ocfs2 storage ocfs2 is 1.4.7-1 for the above kernel (downloaded from oracle oss site) Recently both servers have been crashing with the following error: Assertion failure in journal_dirty_metadata() at fs/jbd/transaction.c:1130: "handle->h_buffer_credits > 0" kernel BUG in journal_dirty_metadata at fs/jbd/transaction.c:1130! We get some kind of kernel debug prompt. the stack is as follows: .ocfs2_journal_dirty+0x78/0x13c [ocfs2] .ocfs2_search_chain+0x131c/0x165c [ocfs2] .ocfs2_claim_suballoc_bits+0xadc/0xd94 [ocfs2] .__ocfs2_claim_cluste...

...ransaction & regain write access for the + * buffer head which is used for metadata modifications. + * Taken from Ext4: extend_or_restart_transaction() + */ +int ocfs2_allocate_extend_trans(handle_t *handle, int thresh) +{ + int status, old_nblks; + + BUG_ON(!handle); + + old_nblks = handle->h_buffer_credits; + trace_ocfs2_allocate_extend_trans(old_nblks, thresh); + + if (old_nblks < thresh) + return 0; + + status = jbd2_journal_extend(handle, OCFS2_MAX_TRANS_DATA); + if (status < 0) { + mlog_errno(status); + goto bail; + } + + if (status > 0) { + status = jbd2_journal_restart(handle, OCFS...

...ff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c index 325bc01..9ddb444 100644 --- a/fs/jbd2/transaction.c +++ b/fs/jbd2/transaction.c @@ -530,6 +530,8 @@ int jbd2__journal_restart(handle_t *handle, int nblocks, gfp_t gfp_mask) lock_map_release(&handle->h_lockdep_map); handle->h_buffer_credits = nblocks; ret = start_this_handle(journal, handle, gfp_mask); + if (ret < 0) + atomic_inc(&transaction->t_updates); return ret; } EXPORT_SYMBOL(jbd2__journal_restart); -- 1.7.9.7

...to 2.4.21 and 2.4.22, as they include the patch reported in the above message. But we're still getting the bug. We can reproduce it using postmark inside versionfs, mounted on top of ext3, in 2.4.22: kernel: Assertion failure in do_get_write_access() at transaction.c:720: "handle->h_buffer_credits > 0" Now, it's quite possible that we're not doing something right in versionfs which messes ext3 up. We're unable to tickle this assertion directly via ext3. However, given that our benchmarks run fine on ext2 and that at least one reported buffer_credits problem was a true...

Hi Mark/Joel, These are 2 bug fix for b-tree. Please review. I have sent out the first one last week, but it was based on cacheme. So resend it. Now it bases on joel's fixes branch. The second one is another b-tree rotation bug. I guess the reason why we never meet with it is that no one has ever used b-tree like reflink before. ;) Regards, Tao

Hi Mark/Joel, This is the v2 of bug fix for ocfs2_add_branch. Modification from V1 to V2: 1. Create a patch which return EROFS instead of BUG in ocfs2_insert_at_leaf. 2. Use ocfs2_adjust_rightmost_records to change the root and extent blocks in the rightmost path. Regards, Tao