search for: buffer_dirty

...into an ext3-0.0.6b fs). Cheers, Andreas =========================================================================== --- fs/jfs/checkpoint.c.orig Thu Mar 1 16:35:40 2001 +++ fs/jfs/checkpoint.c Thu Mar 29 17:08:51 2001 @@ -106,8 +106,15 @@ lock_journal(journal); return 1; } - - if (!buffer_dirty(bh) && !buffer_jdirty(bh) && + + if (bh->b_dev == B_FREE) { + if (bh->b_cp_transaction) { + unlock_journal(journal); + journal_remove_checkpoint(bh); + lock_journal(journal); + return 1; + } + } else if (!buffer_dirty(bh) && !buffer_jdirty(bh) &&a...

...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 ago, except he uses bh->b_jlist == BJ_None. buffer_journaled() seems to be a function in fs.h which seems a...

...nstead of BH_Dirty > for buffers held in the journal. If invalidate_buffers() is called > on a device (LVM likes to do this a lot, for whatever reason), it yanks > JDirty buffers out from underneath the journal layer, and causes an > oops in journal_insert_checkpoint() (line 385, "buffer_dirty(bh) || > buffer_jdirty()" is false). OK, my previous patch cleans up the ASSERT for invalidate_buffers() (modulo the fact that it was missing a ')' 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...

...JBUFFER_TRACE(jh, "add to new checkpointing trans"); __journal_insert_checkpoint(jh, commit_transaction); JBUFFER_TRACE(jh, "refile for checkpoint writeback"); __journal_refile_buffer(jh); } else { + clear_bit(BH_Freed, &bh->b_state); J_ASSERT_BH(bh, !buffer_dirty(bh)); J_ASSERT_JH(jh, jh->b_next_transaction == NULL); __journal_unfile_buffer(jh); --- ./fs/jbd/transaction.c 2002/05/26 23:13:05 1.2 +++ ./fs/jbd/transaction.c 2002/05/28 09:24:45 @@ -1834,6 +1834,7 @@ * running transaction if that is set, but nothing * else. */ JBUFFER_TRAC...

...eck() at jbd-kernel.c:80: "(((bh)->b_state & (1UL << BH_Dirty)) != 0)" -- cut here -- cut here -- cut here -- cut here -- cut here -- Here is line 80 from jbd-kernel.c: -- cut here -- cut here -- cut here -- cut here -- cut here -- J_ASSERT_JH(jh, buffer_dirty(bh)); -- cut here -- cut here -- cut here -- cut here -- cut here -- Then on the reboot, the boot message included this: -- cut here -- cut here -- cut here -- cut here -- cut here -- EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery....

...ext3 branch for 1.0, but it looks like it is important to get it done earlier, so I'll now be working for a 0.0.6 release which reworks the handling of dirty flags in the jfs layer: I'll have to maintain a separate dirty bit to indicate which buffers have modified data, but keep the normal buffer_dirty() flag clear while buffers are journaled. The plan is to go to a kernel-style numbering scheme once we have codefreeze: 0.9 will be the codefreeze for a 1.0 release, but I'll fork a 1.1 branch for developments such as a 2.4 port while 1.0 is kept stable and supported as the baseline 2.2 versio...

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 |

Hi, Is the http://xenbits.xensource.com/linux-2.6-xen.hg tree still being updated? if not, what''s the preferred Linux tree to track that has all of the Xen bits? Thanks, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel