search for: b_jlist

...h file or directory Then, it goes a little farther, 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:1...

Hi, While doing some stress testing with presto module from the intermezzo project layered over ext3, I got the following assertion failure: Jan 17 23:09:55 planck kernel: Assertion failure in jfs_prelock_buffer_check() at journal.c line 410: "bh->b_jlist == 0 || bh->b_jlist == BJ_LogCtl || bh->b_jlist == BJ_IO || bh->b_jlist == BJ_Data" Jan 17 23:09:55 planck kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Jan 17 23:09:55 planck kernel: current->tss.cr3 = 00101000, %cr3 = 00101000 Jan 17 23:09:5...

...all the ext3 filesystems with the -j option to create a hidden journal file. Everything works great ! But. When I plug the second disk in a start a reconstruction, sooner or later within seconds I get an 'ASSERT' failure at line 411 in journal.c. ! It's this line.... J_ASSERT(bh->b_jlist == 0 || bh->b_jlist == BJ_LogCtl || bh->b_jlist == BJ_IO || bh->b_jlist == BJ_Data); Anyone run into this using software raid ? Alan.

...00 Before first symbol Trace; 10002018 Before first symbol Trace; 100019a8 Before first symbol Trace; 10001b54 Before first symbol Trace; 6fed6478 Before first symbol Trace; 00000000 Before first symbol Followed by: Assertion failure in jbd_preclean_buffer_check() at jbd-kernel.c:74: "(jh->b_jlist == 0 || jh->b_jlist == 7 || jh->b_jlist == 5 || jh->b_jlist == 4 || buffer_jbd_data(bh))" kernel BUG at jbd-kernel.c:74! Oops: Exception in kernel mode, sig: 4 NIP: C00538E0 XER: 00000000 LR: C00538E0 SP: C594BDE0 REGS: c594bd30 TRAP: 0700 Using defaults from ksymoops -t elf32-powerpc...

...ed(bh) && (destroy_dirty_buffers || !buffer_dirty(bh))) put_last_free(bh); if (slept) goto again; Stephen suggested something along the above a bit ago, except he uses bh->b_jlist == BJ_None. buffer_journaled() seems to be a function in fs.h which seems a bit more appropriate. Next, with the above we'd still see problems. My next patch included a suggestion from Heinz to add lock_kernel() and unlock_kernel() around the fsync_dev() and invalidate_buffers() in lvm.c/lvm...

Red Hat 2.2.19-6.2.12 + 0.0.7a + https://listman.redhat.com/pipermail/ext3-users/2001-November/002258.html (not tuned in /proc yet) + journal 4MB on each fs + 6 ext3 fs on raid1 (hda+hdc) + 1 ext3 fs on another disk not on raid1 (hdd) While untarring (tar zxf) a file that was on a ext3/raid1 onto hdd I got: ksymoops 2.3.4 on i686 2.2.19-6.2.12.g1. Options used -V (default) -k

...kup.tar ), the cpu load was 99% for a long time. I then stopped it and tried again, but this time this popped up in my ssh session: -- Message from syslogd at rock at Sat Feb 18 00:47:05 2006 ... rock kernel: Assertion failure in __journal_unfile_buffer() at fs/jbd/transaction.c:1520: "jh->b_jlist < 9" -- A kernel panic dump is displayed on the servers monitor. Here is what I can remember: Call trace: jurnal_commit_transaction+<something> [jdb] Is the panic dump stored anywhere? When I rebooted, the raid set was dirty and it was re-synced, it did not mark a drive faulty or...

Jun 29 11:30:05 ns kernel: Assertion failure in __journal_file_buffer() at transaction.c:1935: "jh->b_jlist < 9" Jun 29 11:30:05 ns kernel: invalid operand: 0000 Jun 29 11:30:05 ns kernel: CPU: 0 Jun 29 11:30:05 ns kernel: EIP: 0010:[__journal_file_buffer+54/400] Not tainted Jun 29 11:30:05 ns kernel: EFLAGS: 00010282 Jun 29 11:30:05 ns kernel: eax: 00000059 ebx: c43b92e0 ecx: c47da0...

...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_jlis t != BJ_Data)) + J_ASSERT (!test_bit(BH_JWrite, &buf->b_state)); return; } printk("VFS: brelse: Trying to free free buffer\n"); + J_ASSERT(buf->b_count > 0); } ===== r...

...ever 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("VFS: brelse: Trying to free free buffer\n"); + J_ASSERT(buf->b_count > 0); *(int *)0...

...ile I/O Random number generator seed is 42 Report format is verbose. pm>run Creating files...Done Performing transactions.. Message from syslogd@server at Tue Jun 24 19:24:10 2003 ... server kernel: Assertion failure in journal_dirty_metadata() at fs/jbd/transaction.c:1073: "jh- >b_jlist != 1" Segmentation fault /var/log/messages= Jun 24 19:22:32 server kernel: EXT3-fs: mounted filesystem with journal data mode. Jun 24 19:24:10 server kernel: Assertion failure in journal_dirty_metadata() at fs/jbd/transaction.c:1073: "jh->b_jlist != 1" Jun 24 19:24:10 server...

...If not, I can supply more information, but apart from version numbers I'm not sure what else I could find out. Anyway, here's the output, please let me know if it means anything to anyone! Thanks, Adam. Assertion failure in __journal_unfile_buffer() at transaction.c:1522: "jh->b_jlist < 9" invalid operand: 0000 CPU: 0 EIP: 0010:[<c015d730>] Not tainted EFLAGS: 00010286 eax: 0000005b ebx: cfa42c40 ecx: cfb34000 edx: 00000000 esi: c84784b0 edi: 00000000 ebp: c84784e0 esp: cfb35e64 ds: 0018 es: 0018 ss: 0018 Process kjournald (pid: 30, stackpa...

...d/transaction.c 2003-01-16 02:45:19.000000000 -0800 @@ -669,7 +669,8 @@ repeat: spin_unlock(&journal_datalist_lock); unlock_journal(journal); /* commit wakes up all shadow buffers after IO */ - sleep_on(&jh2bh(jh)->b_wait); + wait_event(jh2bh(jh)->b_wait, + jh->b_jlist != BJ_Shadow); lock_journal(journal); goto repeat; } _

Hi, I've recently been playing about with recent ext3 0.0.6b and lvm 0.9.1 beta7 and am now able to trigger an "Attempt to refile free buffer" assertion. This seems to "only" occur when using ext3 on the root filesystem. Possibly that is related to the fact that the lvm utility I'm using to reproduce this problem is modifying data in /etc. The easist reproduction

The following 6 patches cleanup the jbd code and kill about 200 lines. First of 4 patches can apply to 2.6.13-git8 and 2.6.13-mm2. The rest of them can apply to 2.6.13-mm2. fs/jbd/checkpoint.c | 179 +++++++++++-------------------------------- fs/jbd/commit.c | 101 ++++++++++-------------- fs/jbd/journal.c | 11 +- fs/jbd/revoke.c | 158