T.Tso (the author of btrfs) said it only would be changed if major bugs would be found and there would be no workaround.

Sure, but as the text says, it's still in early state. Ext4 took quite a bit of time to develop, and there were small changes here and there not long before the final release. I wouldn't expect btrfs to stabilize anytime soon. Too early to be trusted as an alternative yet.

This discussion is somewhat over my head but I wanted to say this:

He originally stated that he was using a custom kernel and did not want to try the stock huge kernel.

I can't help but wonder if there is something wrong with his kernel configuration that might be causing the problem. I think it would be a good idea just to try one of the stock kernels before assuming it's a bug if you haven't already done so.

I wonder if ErV can still read this, because his status is " Current Activity: Banned forever - Ban requested ". I'm not sure he's gonna be posting back with a final resolution to the issue.

I think he had what they call "a heated exchange" with the Mods a while ago (or was that someone else?).

Of course his problem might be different than mine, but in my case I've experimented with several kernels and options and I'm convinced that it must be this kernel bug affecting my system. The kjournald solution really improved things here. Before, let alone writing data, even opening a movie with mplayer would take at least 4-5 seconds. Now it's responsive the way it used to be in the old days.

By the way, ErV was also complaining about Firefox in particular. Kernel 2.6.29 fixes a regression in the 2.6.25-28 kernels which drastically hit sqlite performance. Remember that Firefox 3 uses sqlite to store some of its internal data (and yes, I can feel the improvement in Firefox, too).

Also, compiling FF yourself from source with optimizations and certain options can help performance too.

A little update on this (that is, the kernel I/O wait bug):

Kernel 2.6.30 has just been released. It contains some fixes for the latency issues related to ext3 and some CFQ improvements as well. See here for some more details:

http://www.h-online.com/open/Fine-tu...78/1#latencies

I can confirm that it improved my situation a bit. Heavy disk I/O still slows down my system but file transfers seem to be faster. One piece of warning: In the new kernel ext3 is mounted with the option data=writeback by default, unless you choose the old default data=ordered when compiling. Apparently writeback is safe enough to be made the default option, but if you want the highest data security, choose data=ordered as the default in menuconfig or update your fstab. I haven't tried the writeback mode, but it is supposed to bring additional improvements. 2.6.31 is likely to include an intermediate mode which improves things without the risks of writeback.