Description of problem:
Firefox 3 uses sqlite for storage of information like history, bookmarks, etc.
They used to use async i/o, but ran into corruption issues. So they went with
sync i/o which blocks very easily.
Sqlite runs six fsyncs per transaction for history changes. History changes
happen ever time you go to a new page. If you are doing something else on the
system like say a kernel compile, virtual machine image creation, or anything
i/o intensive then the Firefox gui freezes, because it is waiting on the fsync
to finish. I have seen this take literally a minute. Someone in the upstream bug
documented this taking 30 seconds.
The change was introduced in Firefox 3 beta 3. Before then it was async i/o.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Firefox
2. Start Firefox
3. Do something i/o intensive
4. Load new pages
Firefox's ui freezes completely till the fsync completes
Firefox's ui doesn't freeze
The Mozilla developers have said they doesn't consider this a big issue, but for
me it makes Firefox 3 unusable. They have also said they don't plan to fix it
till after the 3.0 release, maybe not till 3.1.
I advocate that either Red Hat patches it to fix Firefox's behavior, or they
downgrade Firefox to 2.0.13.
https://bugzilla.mozilla.org/show_bug.cgi?id=421482 My upstream bug
https://bugzilla.mozilla.org/show_bug.cgi?id=408914 Disabling async i/o bug
I am sorry, we have no resources too keep something so substantial as different
storage background for Firefox.
Closing as WONTFIX.
Note about Firefox 2.0.13 -- we certainly won't downgrade to that, but it will
stay for some time more in Fedora 8, so you can recompile from src.rpm there.
You are willing to ship probably the most used application on the desktop
If you believe it seriously broken, then convince Mozilla that it is. They are
quite reasonable. Fedora tries to stick to upstream as closely as possible, and
I strongly recommend deferring to upstream here.
Choosing between data corruption and slowness is a no brainer, especially given
how many people complained about data corruption and this is the first I've seen
about any slowness. I also compile large items such as xulrunner, firefox, and
openoffice, while running Firefox and have yet to run into any performance issues.
I'll make a few other notes though:
You mention sqlite requires six fsyncs per commit. It may be worth looking into
whether that number can be reduced.
Reading the upstream bug, is this file system related? If so, it may be worth
looking into why this affects some filesystems and not others and attempt to get
fixes into the affected filesystems.
*** Bug 445573 has been marked as a duplicate of this bug. ***
I'll take the liberty of changing this from WONTFIX -> UPSTREAM (per comment #4)
Workaround for this:
a) disable "Tell me if the site I'm visiting is a suspected attack site/forgery"
b) remove the urlclassifier* files in ~/.mozilla/firefox/<profile> (while FF is
Note that this may leave you vulnerable to certain types of attacks.
If that's a viable workaround, before someone does that, can you please attach
those files here so we can try and get a real reproducer?
Here is Mozilla advocating linux distributions to use the current patch on the bug.
*** Bug 448167 has been marked as a duplicate of this bug. ***
*** Bug 449113 has been marked as a duplicate of this bug. ***
*** Bug 451100 has been marked as a duplicate of this bug. ***
This is /killing/ me. I have never been so upset with my desktop experience. I'm
not running much of anything besides firefox. I do tend to keep a number of tabs
open though. I'm not really sure what is triggering it. If developers were
seeing the behavior I'm seeing, they would be racing to fix it.
I find the workaround in comment #7 basically eliminates the problem, if you can
live without the attack site/forgery protection for now.
Firefox 3.0 final will need a patch to set a preference,
toolkit.storage.synchronous, to zero by default for Fedora. The Firefox default
is the same excessive fsync behavior.
I have made my own rc2 rpms, set the preference to zero, and disabled the
attack/forgery options. It is way better, though I still see the interface
freeze while compiling a kernel, but then Thunderbird did the same thing.
On a side note, the type of the preference is integer.
On my system, I don't have to run anything i/o intensive, firefox seems to be
the source of the i/o activity that tends to coincide with the flurries of long
I guess I'll try the workaround for now...
The upstream bug notes that this problem is observed primarily on the Linux ext2
filesystem; presumably it's applicable to ext3 as well.
There are other Fedora packages for major components that contain Linux-specific
patches, so it is not really unheard of to include patches for Linux-specific
Notwithstanding comment #4, when I have 2gb of RAM and have nothing but the
stock Gnome desktop and Firefox loaded, why do I have to wait 20-30 seconds on
every other page load, and is it reasonable to expect ordinary users to go into
about:config in order to fix this?
And when Firefox/kernel decides to grind away for ~20 seconds, if I happen to be
typing in the url field, and the autocomplete dropdown is active, I can't event
switch desktops with CTRL-ALT-left/right! X is completely wedged, until this
hairball passes. This is horrible.
xulrunner-1.9-1.fc9,firefox-3.0-1.fc9 has been submitted as an update for Fedora 9
This was fixed in xulrunner-1.9-1.fc9 via
xulrunner-redhat-default-prefs.js: pref("toolkit.storage.synchronous", 0);
Will this be fixed for all users with an existing profile as well? (They wont
need to flip an option manually?)
If the preference was already set to 1 or 2, it will stay. If it was 0, then it
will change from bold(self set) to normal(default). If it wasn't set, it will be 0.
firefox-3.0-1.fc9, xulrunner-1.9-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.