Hide Forgot
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): firefox-3.0-0.50.cvs20080327.fc9.i386 How reproducible: Always Steps to Reproduce: 1. Install Firefox 2. Start Firefox 3. Do something i/o intensive 4. Load new pages Actual results: Firefox's ui freezes completely till the fsync completes Expected results: Firefox's ui doesn't freeze Additional info: 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 seriously broken?
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" in Preferences->Security b) remove the urlclassifier* files in ~/.mozilla/firefox/<profile> (while FF is not running) 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. https://bugzilla.mozilla.org/show_bug.cgi?id=421482#c71
*** 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 fsyncs. 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 issues. 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.