Bug 439908 - Firefox 3 fsync excessively and ui freezes
Summary: Firefox 3 fsync excessively and ui freezes
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
: 445573 448167 451100 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2008-03-31 22:42 UTC by Nathan G. Grennan
Modified: 2018-04-11 15:40 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-06-17 21:28:52 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Mozilla Foundation 408914 0 None None None Never
Mozilla Foundation 421482 0 None None None Never

Description Nathan G. Grennan 2008-03-31 22:42:59 UTC
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):

How reproducible:

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 16:41:27 UTC
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 16:43:23 UTC
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 17:48:51 UTC
You are willing to ship probably the most used application on the desktop
seriously broken?

Comment 4 Christopher Aillon 2008-04-01 23:43:17 UTC
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 15:16:39 UTC
*** Bug 445573 has been marked as a duplicate of this bug. ***

Comment 6 Rex Dieter 2008-05-16 15:23:58 UTC
I'll take the liberty of changing this from WONTFIX -> UPSTREAM (per comment #4)

Comment 7 Ralf Ertzinger 2008-05-17 12:44:40 UTC
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 15:34:51 UTC
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 23:16:44 UTC
Here is Mozilla advocating linux distributions to use the current patch on the bug.


Comment 10 Matěj Cepl 2008-05-23 21:10:00 UTC
*** Bug 448167 has been marked as a duplicate of this bug. ***

Comment 11 Matěj Cepl 2008-05-30 15:15:28 UTC
*** Bug 449113 has been marked as a duplicate of this bug. ***

Comment 12 Sean Middleditch 2008-06-13 18:15:59 UTC
*** Bug 451100 has been marked as a duplicate of this bug. ***

Comment 13 Mike McLean 2008-06-14 23:31:02 UTC
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 23:48:31 UTC
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 18:45:33 UTC
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 18:48:53 UTC
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 15:52:11 UTC
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...

Comment 18 Sam Varshavchik 2008-06-17 00:17:17 UTC
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.

Comment 19 Fedora Update System 2008-06-17 20:45:53 UTC
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 21:28:17 UTC
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 21:43:45 UTC
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 21:49:46 UTC
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-18 03:15:58 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.