similar to: Re: Bug in __invalidate_buffers?

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

Hello. I found bugs on error handlings in the functions arround the ext3 file system, which cause inadequate completions of synchronous write I/O operations when disk I/O failures occur. Both 2.4 and 2.6 have this problem. I carried out following experiment: 1. Mount a ext3 file system on a SCSI disk with ordered mode. 2. Open a file on the file system with O_SYNC|O_RDWR|O_TRUNC|O_CREAT

I previously wrote: > Stephen writes: > > I'd much rather fix the buffer.c code. Having journaling try to patch > > up after somebody has deleted its buffer heads is very wrong, since we > > risk the buffer journal lists getting badly corrupted if we allow > > those buffers to be reused. > > > Does the patch below (untested, uncompiled!) work? > >

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

This patch fixes an inefficiency and potential system lockup in the 2.4 kernel's ext3 filesystem. The problem has been present since 2.4.20-pre5. This patch is applicable to 2.4.20. A copy is at http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.20/ext3-scheduling-storm.patch Anyone who is using tasks which have realtime scheduling policy on ext3 systems should apply this change.

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

When trying to build ext3 as a module, I get the follwing errors during the kernel link: /usr/bin/kgcc -D__KERNEL__ -I/home/brian/src/kernel-2.2.19-pre6mvd/linux-2.2.19pre6-kdb-ext3/include -c -o dummy_sym.o dummy_sym.c ld -m elf_i386 -T /home/brian/src/kernel-2.2.19-pre6mvd/linux-2.2.19pre6-kdb-ext3/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_t ask.o -Map map

Hi Steven, Hi ext3-users list! We encountered a reproduceable problem with ext3: When issuing a FIBMAP ioctl for a block written right before while the FS is under high load (RH build universe), the assertion !journal->j_running_transaction fails at the bottom of journal_flush() in fs/jbd/journal.c. We encountered this problem with the arch=s390x (64 bit big endian) bootloader zipl, I'll

Hi all, OK, here is ext3-0.0.5e. Changes since 5d are summarised below. The major changes are the barrier support: this infrastructure should be sufficient to allow the snapshotting interface which LVM is wanting for ext3. The journal initialisation fix will also help people adding ext3 to an existing filesystem. Look for ext3-0.0.5e.tar.gz on:

Hello. I have installed the ext3 file system on a test system, and sometimes I have a problem: I get an assert from within jbd-kernel.c, and whatever prgram was writing to the disk when this happens is unable to continue. The system is a server I built, which I named "dax". It is running Debian unstable, and I updated it to all the latest packages in Debian unstable as of today.

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 |

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

Hi. I got following BUG trace. This is violation of BUG_ON(!buffer_locked(bh)) check on submit_bh() function. In write_dev_supers(), if wait parameter is set and buffer_uptodate() check is negative, submit_bh() is executed and hit above BUG_ON. So I fixed this issue. Thanks. Jun 9 00:41:32 dl580 kernel: ------------[ cut here ]------------ Jun 9 00:41:32 dl580 kernel: kernel BUG at

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

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

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

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

Well.... you might remember that I have had problems will my NFS fileserver that run ext3 with data=journal. The filesystem corruption now seems too be solved with the patch (plus amendment) that I posted, so I am happy about that... but there is more. I have known for a while that ext3 doesn't behave very well when the journal fills up. If it finds that the journal is full, and the

I have ext3 0.0.6b + 2.2.19 and cannot get ext3 to compile as a module. If I try to modularize it, or turn in off completely, the kernel build fails. Is there an easy fix for this, or is there something that I am missing? Thanks. Peter