search for: digeo

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

Hi I have mailed about this previously, but back then it was not really confirmed, so I have let it be at that. Anyhow, problem is that for some reason 2.5/2.6 ext3 with HTREE support do not like what perl-5.8.0 does during installation. It *seems* like one of the temporary files created during manpage installation do not get unlinked properly, or gets into the hash (this possible?) and cause

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

Hello Folks, We have 2 (identical hardware) busy public 2U rack servers, both have several hundred users & peak email (for example) deliveries at 300/5min during the daytime. Both servers run RAID1 over 2 EIDE disk drives. One server is fine - it never has problems - it is running RH7.3 and CPU loads are normal. The other server has constant disk activity & kjournald at CPU load of

Hello Andrew, I patched 2.4.20 with your patch found out on http://lwn.net/Articles/17447/ and I have a big problem with: once server is booted on 2.4.20 with your patch, when I want to reboot with /sbin/reboot, server makes a Segmentation fault and it crashs. I tested it on 50-60 servers and it is the same problem. I tested kernel 2.4.20 without your patch: no problem. # uname -a Linux XXXXXX

A change was made to ext3 in 2.4.20-pre9 which will cause the filesystem to run ext3_mark_inode_dirty() against a freed inode. This will occur when an application attempts to add a new file/directory to the filesystem and encounters space or inode exhaustion. The results of this are unpredictable. Usually, nothing happens. But it can cause random memory corruption on SMP, and the kernel will

There are three patches at http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.20/ sync_fs.patch: Fix the ext3 data=journal data-loss-on-unmount bug sync_fs-fix.patch: Fix sync_fs.patch to not deadlock the fs when running `mount -o remount' against a heavily loaded filesystem. ext3-use-after-free.patch Fix a use-after-free bug which can cause memory corruption if the filesystem runs

hm, this backtrace actually has info... btw, I think we need this: --- 25/fs/ext3/namei.c~ext3-brelse-fix Sun Dec 29 06:53:39 2002 +++ 25-akpm/fs/ext3/namei.c Sun Dec 29 06:53:54 2002 @@ -576,8 +576,10 @@ int ext3_htree_fill_tree(struct file *di (hinfo.minor_hash < start_minor_hash))) continue; if ((err = ext3_htree_store_dirent(dir_file, - hinfo.hash,

[Re-sending to the ext3 list, with minor edits] I'm in the process of fixing errors generated by the Coverity tool on the Linux kernel, and I would like your comment on a set of problems reported in ext3. The main issue reported is not checking the return code of ext3_journal_get_write_access() in various places. I would like to know if there should be error handling in these cases. The

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.

In 2.4.20-pre5 an optimisation was made to the ext3 fsync function which can very easily cause file data corruption at unmount time. This was first reported by Nick Piggin on November 29th (one day after 2.4.20 was released, and three months after the bug was merged. Unfortunate timing) This only affects filesystems which were mounted with the `data=journal' option. Or files which are

This patch fixes the data loss which can occur when unmounting a data=journal ext3 filesystem. The core problem is that the VFS doesn't tell the filesystem enough about what is happening. ext3 _needs_ to know the difference between regular memory-cleansing writeback and sync-for-data-integrity purposes. (These two operations are really quite distinct, and the kernel has got it wrong for