similar to: 0.0.6b conflict with raid patch

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

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

I desperately need the ability to quickly recover from a power loss so I am finally going to break down and spend some time with ext3. I dl'ed the ext3-0.0.6b.tar.gz and unzipped it in /usr/src. Then I installed kernel-source-2.2.19-6.2.1.i386.rpm from redhat I then treid to apply the patches: cat ../ext3-0.0.6b/linux-2.2.19pre14.kdb.diff | patch -sp1 cat

Our main NFS-server, running Debian Potato, died this morning whilst under quite heavy load - due to a runaway perl-script forking of some 200 instances of "/bin/cp" (the load was ~ 50). The server is running 2.2.19pre14 with ext3-0.0.6b. The server is running kernel-nfs. Assertion failure in journal_dirty_metadata() at transaction.c line 796: "bh->b_next_transaction ==

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

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

Hi all, ext3-0.0.6b is now available at the usual places: ftp.*.kernel.org:/pub/linux/kernel/people/sct/ext3/ and ftp.uk.linux.org:/pub/linux/sct/fs/jfs/ The only significant change in this release is the fix to the orphan list recovery, and that fix also affects e2fsprogs, so please pick up the new e2fsprogs from the same directory when you grab the ext3 release. I've put tarballs,

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

One of our users here got the following with an ext3 0.0.6b: # debugfs /dev/hda3 debugfs 1.20-WIP, 17-Jan-2001 for EXT2 FS 0.5b, 95/08/09 /dev/hda3: Bad magic number in super-block while opening filesystem debugfs: Does debugfs need updating? b.

Hi, i am seeing an oops (every couple of days) on a UP PII system with SCSI disks, Kernel 2.2.19 and ext3 0.0.6b. All oops output passed the klogd thus i cant anymore pipe it through ksymoops - I ensured klogd got the correct System.map so the result should be reliable. Apr 25 17:03:10 Unable to handle kernel paging request at virtual address 8efd1fc8 current->tss.cr3 = 0981e000, %%cr3 =

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

Hi, I wanted to implement some QOS on my Linux Box with HTB, but after some time spend on the configuration and tests, I still don''t manage to have some correct results. Here are the details : -ROOT 2000 kbits -HIGHPRIO SUBCLASS 50 kbits prio 0 -SUBCLASS1 750 kbits prio 1 -SERVICE1 250 kbits prio 1

Hi again, I keep posting about my problem with HTB -> http://mailman.ds9a.nl/pipermail/lartc/2005q3/016611.html With a bit of search I recently found the exact same problem I have in the 2004 archives with some graphs that explain it far better than I did -> http://mailman.ds9a.nl/pipermail/lartc/2004q4/014519.html and http://mailman.ds9a.nl/pipermail/lartc/2004q4/014568.html

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: We are using ext3 on a set of machines running a 2.2 kernel. We are running 2.2.19 with the ext3-0.0.6b patch. All has been good until we moved to a new type of machine. Can someone point us to the latest 2.2 patches? We'd like to look at the changelogs between 0.6b and the latest to see if the symptoms we are seeing may be addressed under the latest patch. We cannot move to

After a rather severe hard boot, my machine refuses to mount homes, which are on an ext3 partition. Here is the error i get while mounting... # mount /dev/sdc1 EXT3-fs: invalid journal inode EXT3-fs: get root inode failed mount: wrong fs type, bad option, bad superblock on /dev/sdc1, or too many mounted filesystems However I am able to mount it as ext2 and continue. I am using ext3-0.0.6b on

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) >

Apologies for a vague and wooly bug report, but I can't reproduce this on my test systems - I *can* reproduce it on some production ones like a flash.... but that seems to upset our operations guys :-( I am getting a set of crashes on some boxes in the field, apparently related to high network traffic (this only occurs on boxes with ethernet connectivity back to the centre rather than the

For some time now I have been puzzled as to why certain portions of my system boot were quite slow -- but only after journal recoveries. I was fearing that there was some ugly interaction between the recovery and the use of the journal shortly afterward but alas that is not the case. So just in case anybody else is seeing this problem and decides to try to hunt it down, let me save you some

Hi! A few weeks ago we upgraded 9 large webservers from ext2 to ext3. Since then we've seen very strange behavior on several of the machines. Permissions of files are repeatedly changed at random occasions. Several times, ownership of files have been totally mangled. Several users have logged in to discover that all their files suddenly are owned by another user! At two of these occasions