Hi,
      I've just done that, reinstalled my machine by putting ext4 on / (and
/home) and keeping my data on a separate ext3 partition.

I can only say one word: WOW!

Jaunty coupled with ext4 is super fast. Previoulsy my disk was pretty busy,
especially during startup, with a lot of IO activity. I watch IO activity
all the time, since it is actually my bottleneck.

After the upgrade, I almost _NEVER_ see any IO activity!!! I suspect ext4
delayed allocation is the key here, along with the fact that I reinstalled,
my previous filesystem had certainly some fragmentation (upgraded since
Gutsy).

So I would suggest anybody to deploy a similar approach: ext4 on / and data
in a separate ext3 partition.

Furthermore with Jaunty I noticed that preload is not necessary anymore, it
seems that the filesystem cache is already primed. Many application start up
much faster!

I have a 8-years old PC with 512MB of RAM that now feels like a new machine.

My best congratulations to all the devs :)

2009/4/11 Alexander Sack <email address hidden>

> On Mon, Mar 23, 2009 at 02:15:00AM -0000, R (Chandra) Chandrasekhar wrote:
> > Alexander Sack wrote:
> > > in anycase, if you still have an issue in jaunty you could also
> > > test ext4 filesystem which should help to make the filesystem access
> > > done by firefox less IO hungry.
> >
> > Thanks for that hint. I need clarification on the ext4 filesystem:
> >
> > 1. Will it be an option in jaunty?
>
> Yes, from what i can recall its available as an option in the jaunty
> installer. However, its still not 100% finished (which is reflected by
> the fact that its still not the default for us).
>
>
> >
> > 2. Is it enough for the root partition / to be ext4 or should the /home
> > partition also be ext4?
>
> The write operation happens on your /home partition, so migrating that
> to ext4 should help. However, remember that with ext4 keeping regular
> backups is even more important.
>
>  - Alexander
>
> --
> after fix for #215728 - Committing to urlclassifier3.sqlite still causes
> excessive CPU usage and disk I/O (the 2nd)
> https://bugs.launchpad.net/bugs/229745
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Mozilla Firefox Browser: Invalid
> Status in “firefox-3.0” source package in Ubuntu: Invalid
> Status in “xulrunner-1.9” source package in Ubuntu: Won't Fix
> Status in firefox-3.0 in Ubuntu Hardy: Invalid
> Status in xulrunner-1.9 in Ubuntu Hardy: Won't Fix
> Status in firefox-3.0 in Ubuntu Intrepid: Invalid
> Status in xulrunner-1.9 in Ubuntu Intrepid: Won't Fix
>
> Bug description:
> Binary package hint: firefox
>
> some follow up comments from bug #215728
>
> [ https://bugs.edge.launchpad.net/ubuntu/+bug/215728/comments/118 ]:
>  Yes, there is still some heavy disk I/O going on. It's no where near as
> bad as it was before the update. This patch is a HUGE
>  improvement, but it still happens from time to time causing Firefox to
> become unresponsive for a few seconds.
>
>
> [ https://bugs.edge.launchpad.net/ubuntu/+bug/215728/comments/120 ]
>   actually I've just measured some firefox heavy IO activity, but as Nick
> reported, it is a matter of seconds and in my case it doesn't make the whole
> system irresponsive as it was before the patch.
>
> Luckily I had disktop running, so here is the output. I can say that the
> the slowdown that I felt was probably due to the large write of 5.5MB in 5
> seconds you can see at 18:28:31 - some random IO activity I guess.
>