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 <a...@jwsdot.com> > 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. > -- 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 member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs