Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Firefox 3 fsync excessively and ui freezes|
|Product:||[Fedora] Fedora||Reporter:||Nathan G. Grennan <redhat-bugzilla>|
|Component:||firefox||Assignee:||Gecko Maintainer <gecko-bugs-nobody>|
|Status:||CLOSED NEXTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||ahoffsta, amlau, bob.bogo, esandeen, jbastian, jik, mcepl, mikem, mishu, mrsam, pierre-bugzilla, robatino, sean, tim, tjb, tla, wtogami|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-06-17 17:28:52 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Nathan G. Grennan 2008-03-31 18:42:59 EDT
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
Comment 1 Matěj Cepl 2008-04-01 12:41:27 EDT
I am sorry, we have no resources too keep something so substantial as different storage background for Firefox. Closing as WONTFIX.
Comment 2 Matěj Cepl 2008-04-01 12:43:23 EDT
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.
Comment 3 Nathan G. Grennan 2008-04-01 13:48:51 EDT
You are willing to ship probably the most used application on the desktop seriously broken?
Comment 4 Christopher Aillon 2008-04-01 19:43:17 EDT
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.
Comment 5 Christopher Aillon 2008-05-16 11:16:39 EDT
*** Bug 445573 has been marked as a duplicate of this bug. ***
Comment 6 Rex Dieter 2008-05-16 11:23:58 EDT
I'll take the liberty of changing this from WONTFIX -> UPSTREAM (per comment #4)
Comment 7 Ralf Ertzinger 2008-05-17 08:44:40 EDT
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.
Comment 8 Christopher Aillon 2008-05-20 11:34:51 EDT
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?
Comment 9 Nathan G. Grennan 2008-05-20 19:16:44 EDT
Here is Mozilla advocating linux distributions to use the current patch on the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=421482#c71
Comment 10 Matěj Cepl 2008-05-23 17:10:00 EDT
*** Bug 448167 has been marked as a duplicate of this bug. ***
Comment 11 Matěj Cepl 2008-05-30 11:15:28 EDT
*** Bug 449113 has been marked as a duplicate of this bug. ***
Comment 12 Sean Middleditch 2008-06-13 14:15:59 EDT
*** Bug 451100 has been marked as a duplicate of this bug. ***
Comment 13 Mike McLean 2008-06-14 19:31:02 EDT
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.
Comment 14 Andre Robatino 2008-06-14 19:48:31 EDT
I find the workaround in comment #7 basically eliminates the problem, if you can live without the attack site/forgery protection for now.
Comment 15 Nathan G. Grennan 2008-06-15 14:45:33 EDT
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.
Comment 16 Nathan G. Grennan 2008-06-15 14:48:53 EDT
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.
Comment 17 Mike McLean 2008-06-16 11:52:11 EDT
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...
Comment 18 Sam Varshavchik 2008-06-16 20:17:17 EDT
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.
Comment 19 Fedora Update System 2008-06-17 16:45:53 EDT
xulrunner-1.9-1.fc9,firefox-3.0-1.fc9 has been submitted as an update for Fedora 9
Comment 20 Nathan G. Grennan 2008-06-17 17:28:17 EDT
This was fixed in xulrunner-1.9-1.fc9 via xulrunner-redhat-default-prefs.js: pref("toolkit.storage.synchronous", 0);
Comment 21 Warren Togami 2008-06-17 17:43:45 EDT
Will this be fixed for all users with an existing profile as well? (They wont need to flip an option manually?)
Comment 22 Nathan G. Grennan 2008-06-17 17:49:46 EDT
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.
Comment 23 Fedora Update System 2008-06-17 23:15:58 EDT
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.