search for: b_count

...r, and I get an Assertion. I turned on the buffer header debugging, and here's the output: buffer trace for buffer at 0xc02db000 (I am CPU 0) journal_dirty_metadata() [transaction.c:1101] file as BJ_Metadata b_state:0xb1 b_list:BUF_CLEAN b_jlist:BJ_Metadata on_lru:1 cpu:0 on_hash:1 b_count:2 b_blocknr:1 b_jbd:1 b_frozen_data:00000000 b_committed_data:00000000 b_transaction:1 b_next_transaction:0 b_cp_transaction:0 b_trans_is_running:1 b_trans_is_comitting:0 b_jcount:0 <0> journal_dirty_metadata() [transaction.c:1106] exit b_state:0xb1 b_list:BUF_CLEAN b_jli...

I get 2 rejects applying 2.2.19-ext3 to latest errata rh 2.2.19 kernel. 1) fs/buffer.c Should I put "J_ASSERT(buf->b_count > 0);" before or after " *(int *)0 = 0;"? ===== ext3 0.0.7a patch --- 934,946 ---- if (buf->b_count) { buf->b_count--; + if (!buf->b_count && + (buf->b_jlist != BJ_None && buf->b_jlist != BJ_Shadow && buf->b...

Assertion failure in journal_add_journal_head() at fs/jbd/journal.c:1679 : "(((&bh->b_count)->counter) > 0) || (bh->b_page && bh->b_page->mapping)" ------------[ cut here ]------------ kernel BUG at fs/jbd/journal.c:1679! invalid operand: 0000 [#2] CPU: 0 EIP: 0060:[<c017637f>] Not tainted EFLAGS: 00010282 EIP is at journal_add_journal_head+0x70/...

...;)' at the end of the line) > but it hasn't really fixed the whole problem. If a file write is in > progress when invalidate_buffers() is called, I get an oops: > The oops is caused from __invalidate_buffers() calling put_last_free(bh) > on the device buffers (for buffers with b_count == 0 and not dirty), which > must conflict somehow with what jfs expects of the state of a buffer. It > seems we would not have this problem if bh->b_count was non-zero. I'm having a bit of a one-sided conversation here, but that's OK because I am at least able to stop the oops f...

...le_write do_readv_writev sys_write The oops is from "*(char *)0 = 0" added by the ext3 patch, but I take it that trying to refile a free buffer is fundamentally a bad thing. The oops is caused from __invalidate_buffers() calling put_last_free(bh) on the device buffers (for buffers with b_count == 0 and not dirty), which must conflict somehow with what jfs expects of the state of a buffer. It seems we would not have this problem if bh->b_count was non-zero. What I'm just testing is checking if a buffer is B_FREE before calling refile_buffer() on it, and just doing journal_remove_...

...ed directly to invalidate_buffers() being called which then triggers refile_buffer() on a journaled buffer, which appears clean in all other ways according to the checks in refile_buffer(). The following is what I've got in __invalidate_buffers() right now. if (!bh->b_count && !buffer_journaled(bh) && (destroy_dirty_buffers || !buffer_dirty(bh))) put_last_free(bh); if (slept) goto again; Stephen suggested something along the above a bit...

...ause telnetd was killed> I umounted and remounted ext2, performed 10 bonnie runs at -s200 and never got the same problem again; it seems "free" in vmstat never dropped below 1000 with ext2. This is how I solved the 2 ext3 rejects 1) fs/buffer.c @@ -908,9 +933,13 @@ if (buf->b_count) { buf->b_count--; + if (!buf->b_count && + (buf->b_jlist != BJ_None && buf->b_jlist != BJ_Shadow && buf->b_jlis t != BJ_Data)) + J_ASSERT (!test_bit(BH_JWrite, &buf->b_state)); return; } printk("VF...

Continuing on with my earlier post . . . after looking through code of JBD, is the following perhaps the difference in why the md5 values differ; When a journalled filesystem that uses jbd is mounted the journal b_count is incremented by one? *EVEN* if the volume was mounted read only, this b_count is still increased by one? curious as ever! lt __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com

make spotless leaves 2 generated files. diff -purN klibc-0.159.orig/klibc/Makefile klibc-0.159/klibc/Makefile --- klibc-0.159.orig/klibc/Makefile 2004-08-03 23:07:05.000000000 +0200 +++ klibc-0.159/klibc/Makefile 2004-08-13 22:23:35.696699671 +0200 @@ -156,6 +156,7 @@ clean: archclean rm -f sha1hash errlist.c spotless: clean + rm -f include/klibc/havesyscall.h syscalls.nrs find . \( -name

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

Hi, A system running ext3 crashed this afternoon (nothing to do with ext3, bad network driver). Is was saving a file from emacs when it happened. The file system is 0.06b and had ordered data as the mount option. Let me emphasize this was running ext3 pure, not with SnapFS or InterMezzo layered on top of it. strace reveals that Emacs does open("existing file name", O_TRUNC |