similar to: EXT3 deadlock in 2.4.22 and 2.4.23-pre7 - quota related?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Background: Large NFS/mail server. Dual PIII/1GHZ. 4GB memory. Mylex AcceleRAID 352 RAID controller (uses DAC960 driver). Intel eepro100 network cards. RedHat 7.3 with all errata. Kernel-2.4.18-5smp. 2GB of memory is used by a RAM disk for mail queue. ext3 filesystems (switched to ext2 to see if that helps). one large (100GB data partition).

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 Stephen, it's me again with a problem report about quotas and ext3... I'm not quite sure whether you tried to resolve the quota problems yet, but since I read in the changelog of 0.0.5e that you included some quota specific fixes I decided to give a try (again). And once again: Bad news. Still lockups, reliable reproducible. But this time I have a little backtrace for you of two

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

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.

First I will apologize for posting my patch here if this is not the correct place to post a patch. I know that smbfs is being removed, but we still use it and need it to work. We have a patch to contribute back to the smbfs in the 2.6 kernel. I have noticed multiply posts on this issue and we have basically patch the smbiod.c to fix the reconnect bug in 2.6 Something we did for our patch is

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

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

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

Hello, I've attached the output from "sh scripts/ver_linux" per the bug reporting guidelines, and a diff of the file fs/jbd/transaction.c. At this point, I'm trying to hunt down why some system threads, which are executing the Lustre file system code, are taking an unexpectedly long time executing various ext3 file system functions. I added some debug code to these system

I've been running into a kernel panic pretty consistently when using data=journal. This occurs during heavy IO, and is highly reproducible (only takes about 5 minutes of IO to cause it). The applications being used are MySQL, Postfix, and a mail filtering application which operates on postfix queue files using mmaped IO. Shortly before the crash, the following messages are logged: Mar

http://www.sample.banga.lt/crash.gif System - fully (except kernel) updated RedHat 7.3. Filesystems - ext3 in default ordered mode. What could be the cause of the crash? Kernel update will solve the problem? Thanks, Mindaugas

I have a NFS server with stock 2.4.20 patched with the 5 data=journal patches, plus the 2.4 LSM and NSA's selinux. The partition is mounted with the options: rw,noatime,nosuid,nodev,data=journal,errors=remount-ro The oops seems to happen when the fs is under load. I don't think I encountered this behavior with a non LSM/selinux kernel, so it may have something to do with those, but I

All, I am running into a situation in which one of my ext3 filesystems is getting hung during normal usage. There are three ext3 filesystems on a CompactFLASH. One is mounted as / and one as /tmp. In my test, I am copying a 100 MB file from /root to /tmp repeatedly. While doing this test, I eventually see the copying stop, and any attempts to access /tmp fail - if I even do ls /tmp the

Hello ext3-users-request, request ======= 2004-03-03 12:00:00 You writed======= >Send Ext3-users mailing list submissions to > ext3-users at redhat.com > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/ext3-users >or, via email, send a message with subject or body 'help' to > ext3-users-request at redhat.com >

Hi, More than 1000''s of classes and filters gets created/deleted in run time. Are we doing it correctly( as our requirement is such). Since few days we are facing lots of problems, like the server gets hanged, we get some junk messages in our logs. we have to reboot our server every now and then. What is the max limit of classes/filters can be created. we are using redhat 7.3.

Kill warning if CONFIG_QUOTA is disabled. --- linux-2.4.23/fs/ext3/super.c.orig Fri Nov 28 21:04:40 2003 +++ linux-2.4.23/fs/ext3/super.c Sun Nov 30 12:16:00 2003 @@ -449,7 +449,6 @@ } static struct dquot_operations ext3_qops; -static int (*old_sync_dquot)(struct dquot *dquot); static struct super_operations ext3_sops = { read_inode: ext3_read_inode, /* BKL held */ @@ -1773,6 +1772,8 @@

Hi All, Is http://thunk.org/tytso/linux/ext3-dxdir/patch-ext3-dxdir-2.4.21rc5 the latest htree patch for 2.4 or should I be using bitkeeper to extract the patch?

Hi! I was updated kernel from 2.4.22 to 2.4.23 and now tc tools can''t correctly determine default (pfifo_fast) qdisc on interface: # tc/tc qdisc ls dev ppp0 qdisc pfifo_fast 0: [Unknown qdisc, optlen=20] but, if I assign f.e. cbq qdisc for some device all show correctly: # tc/tc qdisc ls dev ppp1 qdisc tbf 8009: rate 32Kbit burst 10Kb lat 1.5s qdisc cbq 66: rate 10Mbit

I've tagged a release for libdrm 2.4.23 principally to expose the new kernel parameters for BLT support on SandyBridge and relaxed fencing which are needed to build the next release of xf86-video-intel. However, I'm lacking sufficient privileges to actually upload the tarballs myself at the moment, so you'll have to make do with the git tag! -Chris Adam Jackson (1):