similar to: 0.0.7a + rh2.2.19: help solve rejects

SYSTEM: rh6x based system, 2.2.19-6.2.7 rh errata kernel + 0.0.7a patch, I rebuilt rpm for i686; celeron466, 64MB, PIIX4. root fs is on software raid1 ext2, 6 additional fs's on software raid1 ext2. There's a 3rd HD, not mirrored, which is mounted ext3. EXT3-fs: mounted filesystem with ordered data mode. I enabled journal with tune2fs -j with unmounted fs. The 3 HDs are tuned with

Hello all, I am trying to integerate 0.0.6b with our kernel RPM here and have come across an interesting conflict. I want to include the raid patch that Red Hat includes in their kernel but that patch includes the following hunk: --- linux/include/linux/fs.h.orig Tue Jan 16 13:30:09 2001 +++ linux/include/linux/fs.h Tue Jan 16 13:47:18 2001 @@ -191,6 +191,7 @@ #define BH_Req 3 /* 0 if the

All, I know that there is no official port to Kernel 2.4.4, thus I may not get any help, however I am hoping someone could point me in the right direction for my problem. I am currently forced to use kernel 2.4.4 for reasons out of my control (embedded board). Here are the exact versions of everything I'm running: ExT3 Version: ext3-2.4-0.9.6-248 Util Version: util-linux-2.11f.tar.bz2 e2fs

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

I previously wrote: > 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 called, I get an oops: > The oops is caused from __invalidate_buffers() calling put_last_free(bh) >

I previously wrote: > I have come across what appears to be a bug in __invalidate_buffers() > w.r.t. the change in ext3-0.0.6 using BH_JDirty instead 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

I think I have this one solved, I hope. I think what Andreas and I are running into are a few different assertions. One being the LVM lvm_do_pv_flush caused assertion which is related 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

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

Hi, I found the following, suspect looking, gem in ext3-2.4-0.9.1-246.gz. Is this supposed to compile or is it just a tyypo ? +enum jbd_state_bits { + BH_JWrite + = BH_PrivateStart, /* 1 if being written to log (@@@ DEBUGGING) */ + BH_Freed, /* 1 if buffer has been freed (truncated) */ Rik -- Virtual memory is like a game you can't win; However, without

Signed-off-by: Alexey Dobriyan <adobriyan at mail.ru> Index: linux-2.6.10-bk11-warnings/fs/ext3/inode.c =================================================================== --- linux-2.6.10-bk11-warnings/fs/ext3/inode.c (revision 11) +++ linux-2.6.10-bk11-warnings/fs/ext3/inode.c (revision 12) @@ -803,7 +803,7 @@ if (create) { handle = ext3_journal_current_handle(); - J_ASSERT(handle

Hi Stephen, I'm one of developers of SnapFS, which based on Ext3. I got Assertion 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

I've just set up a brand new system with software raid1 (in degraded mode) with one IDE 20GB drive, using kernel 2.2.19pre16 with ext3 0.0.6b. It's split like this.. 32MB /dev/hda1 /boot 2GB /dev/hda2 / ~18GB /dev/hda3 /home all partitions are marked as 0xfd (autostart raid) with the patches from http://people.redhat.com/mingo/raid-patches for 2.2.17. And I've made all the ext3

Hi, as I mentioned in earlier mail to ext3-users I have been getting some corruption on an ext3 filesystem that has been serving NFS. I am now confident that I fully understand the problem and have a patch. It only affects data=journal mode and I wonder if it might also be the cause of the corruption noted by a number of people on linux-kernel. First I will explain the problem. Then display

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

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

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

Started with buffer.c v1.19. Reversing change works for me in linux-2.4.6. Loaded 16705 symbols from /lib/modules/2.4.6-pre3/System.map. Symbols match kernel version 2.4.6. Loaded 256 symbols from 12 modules. Linux version 2.4.6-pre3 (root@home1) (gcc version 2.95.3 20010315 (release)) #2 Wed Jun 13 19:53:28 EDT 2001 ----- SNIP ------- VFS: Disk change detected on device ide1(22,64) Assertion

jbd2_journal_restart() would restart a handle. In this function, it calls start_this_handle(). Before calling start_this_handle()?subtract 1 from transaction->t_updates. If start_this_handle() succeeds, transaction->t_updates increases by 1 in it. But if start_this_handle() fails, transaction->t_updates does not increase. So, when commit the handle's transaction in

Hi everyone, I've been reading this mailing list once in a while and I have seen that there are quite a few bugs that were resolved since EXT 0.0.7a. I was wondering if using 0.0.7a with kernel 2.2.19 is dangerous or ok because I have had some corrupted files once in a while (using compact flash disk CF on IDE bus). 0.0.7a is the only patch available for kernel 2.2.19 to my knowledge are

Hello, Now that kernel 2.2.20 is out with security fixes, I'd be interested in using it with ext3. The latest patch for 2.2.19, 0.0.7a, applies with some offset (both with and without kdb), and even compiles (without kdb), but I scarcely know what I am doing so haven't tried it yet. Could people in the know enlighten me on that point? I guess there is little chance for another ext3