similar to: Regarding hashing, ext3, and kjournald

I am using SuSE 7.3 compiled ext3 support into the kernel and installed it. All my partitions load up as ext3 except / . I ran tune2fs several times, still doesn't take on the / drive. Most recent dumpe2fs -h show no features on that drive=, I keep going around in circles, removing .journal from / and running tune2fs but it never works for / What am I doing wrong? ( thanks in advance)

Hi, I've recently installed ext3 on an 800MB RAID5 (software) array. I am running RedHat Linux 7.1 with the Linux kernel 2.4.12-ac3 on a 1GHz Pentium system with 128MB RAM. I am seeing a significant amount of write operation slowdown when running ext3 (and kjournald), as opposed to my old ext2. The problem seems to be associated with the times that kjournald is accessing the disk. At

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, we have just observed a rather annoying behavior one of our servers. Specifically, when writing data to a file on an ext3fs filesystem at around 1.5 MB/sec, network connectivity suddently started to show signs of lag. The ping would spike up to ~1 second every 5 seconds or so. This affects the server in question and all hosts routing traffic through it (i.e., it's not a userland-only

I have a system on which kjournald becomes blocked in D state quite often. Looking at a core file we have 5 mounted ext3 filesystems: crash> mount VFSMOUNT SUPERBLK TYPE DEVNAME DIRNAME 10037e07b00 10037e4ec00 rootfs rootfs / 10037e07ec0 10037e4e400 proc /proc /proc 10037e07d40 102188abc00 tmpfs

(Sent to linux-raid, linux-kernel and ext3-users since I'm not sure what type of issue this is) I've got a test system here running Redhat 7.1 + stock 2.4.9 with these patches: http://www.fys.uio.no/~trondmy/src/2.4.9/linux-2.4.9-NFS_ALL.dif http://www.zip.com.au/~akpm/ext3-2.4-0.9.6-249.gz http://domsch.com/linux/aacraid/linux-2.4.9-aacraid-20010816.patch All three patches applied

Hi, I am getting the following Oops on 2.6.30.1 kernel. The bad part is, it happens rarely (twice in last 1.5 months) and the system is pretty lightly loaded when this happens (no heavy file/disk io). Any insights or patches that I can try? (i searched lkml and ext3 lists but could not find any similar oops/reports). == Oops =================== BUG: unable to handle kernel NULL pointer

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

I am getting an odd situation when backing up a number of ext3 filesystems and was wondering if it could be caused by journalling. Over the space of a minute the load average will jump from 2 to over 40 and the system will be unresponsive for anywhere from 8 to 25 minutes. I am going to be trying a number of things, but was wondering if anyone could see the reason for the high load given the

Hello List, Running 2.4.21-pre3-ac1 SMP with new quotas (usr and grp), this oops showed up while copying a large amount (about 50gigs, only 1.6 made it before the oops). I'm trying to reproduce as we speak. Unable to handle kernel NULL pointer dereference at virtual address 00000004 c0130956 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[<c0130956>] Not tainted Using defaults

While investigating erratic performance on one our our servers, I'm getting some very odd performance stats coming from vmstat. What initially appeared to be happening is the machine goes into a hard loop in some mod_perl webserver code. Now there still may be an issue with the code, but my code examinations show no possible way this could be happening, but what I'm writing to you

I'm getting oops whenever I pull a big file off of an ext3 filesystem on my large LV. The kernel this comes from happens to have lvm 1.0.2 and posix ACL for ext2/3 patched in, but I get the crash even on vanilla 2.4.17. kymoops 2.4.3 on i686 2.4.17-acl-lvm. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.17-acl-lvm/

Hello, Sorry for the off-topic, but I've just installed CentOS 5 on my home box and I want to put the journal on another drive. I created a software RAID-1 device, /dev/md1, and formatted an ext3 file system on it. Now I want to move the journal to /dev/hda5. I've googled for this and the process appears to be: mkfs.ext3 -b 4096 -O journal_dev /dev/hda5 mkfs.ext3 -b 4096 -J

Hello everybody, Could someone please explain to me what is the difference between kjournald and jbd (precisely, what does each of them do?) Thank you, Alina _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

kernel version 2.6.10-1.771_FC2smp We have had quite a few instances of kjournald pegging cpu and thereby effectively knocking out the system's i/o. What can we do to provide more information so that the cause can be identified and fixed? Thanks Christopher

Hi,guys In my server, the process kjournald used much more cpu time. How can I let my system load down? Thanks. Forrest Wang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/ext3-users/attachments/20070417/67bf3e94/attachment.htm>

Today our mailserver froze after just one day of uptime. I was able to capture the Oops on the screen using my digital camera: http://www.stahl.bau.tu-bs.de/~hildeb/bugreport/ Keywords: EIP is at journal_commit_transaction, process kjournald # mount /dev/cciss/c0d0p6 on / type ext3 (rw,errors=remount-ro) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts

Hello! While performing some zttest's for some time today, I was also keeping an eye of a top of the machine. While the zttest was running, I also had a ssh-keygen and a dd creating a 5GB file on an EXT3 partition running. I noticed that for the most part, I got a decent number of 100%'s, and a bunch of 99.6%'s or higher. However, it seems that whenever the zttest dropped

Hi, I've got a Redhat 7.2 system: Celeron 400 512MB RAM 18GB SCSI HD (/boot (ext2fs), / (ext3fs)) 40GB IDE HD (/ (ext3fs)) I run a bunch of services on the box (apache + mod_perl, MYSQL, Samba, etc) but the system is not under heavy load. This system has performance issues reading/writing to the ext3fs filesystems. The performance issues cropped up when I installed Redhat 7.2. Previously

We run several RH7.2/7.3 servers & recently 2 of them, although still working fine, have started to show kjournald as generally using over 50% cpu% on 'top' - virtually continuously. Free cpu% generally less than 25% now! Both machines are also using software RAID5 EIDE ....... otherwise are standard server installs. Any info on what kjournald is & why it should have recently