Firefox keeps forcing disk to spin up when browsing because its sqlite storage calls fsync() for every recorded entry

[Dennis Noordsij]

Binary package hint: firefox-3.0

Background: when running in laptop-mode, all writes to the disk are postponed until a scheduled disk spinup, this saves power. Only an uncached read, or an explicit fsync(), causes the disk to spun up outside of the scheduled spinups (every 10 minutes or so?).

(This is Ubuntu Hardy RC, with Firefox 3b5)

Firefox uses sqlite to save certain data (I guess including history).

This prevents laptop-mode from running effectively, since whenever Firefox records a new entry (i.e. you browse to a page), its sqlite storage calls fsync(), which in turns forces the disk to spin up. Laptop mode in general seems to be quite efficient, with Firefox being the only cause of increased spinups for me.

Sqlite does support a nosync mode, which could be enabled while in laptop-mode. IMO it would be worth to at least enable the option to lose some history in a (system) crash (which is only while in laptop-mode), if it means Firefox can be used in laptop-mode. Currently, just browsing with Firefox causes so many spinups the power savings are nil, and the Load_Cycle_Count increases way too fast.

Example:

[75250.049865] pdflush(31873): WRITE block 109142072 on dm-2

.... last write
.... then 323 seconds of disk in spun down state ..
.... then in firefox clicking a link

[75613.477491] firefox(21767): dirtied inode 4784757 (places.sqlite-journal) on dm-2
[75613.477517] firefox(21767): dirtied inode 4784757 (places.sqlite-journal) on dm-2
[75613.478586] firefox(21767): dirtied inode 4784273 (places.sqlite-stmtjrnl) on dm-2
[75613.478599] firefox(21767): dirtied inode 4784273 (places.sqlite-stmtjrnl) on dm-2
[75613.479031] firefox(21767): WRITE block 76662616 on dm-2

... and now the writing starts because of the fsync() of sqlite.

A user would expect that on a "worn-in" desktop (i.e. basically everything you use is in cache) normal web browsing should not cause a sync (or read) event for every page. Webbrowsing is probably one of the most common activities on laptops running on battery, and Firefox is the most popular webbrowser in Ubuntu.

ProblemType: Bug
Architecture: i386
Date: Wed Apr 23 14:50:56 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: nvidia
Package: firefox-3.0 3.0~b5+nobinonly-0ubuntu3
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=nl_NL.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-16-generic i686

[Dennis Noordsij (dennis-noordsij)]

Binary package hint: firefox-3.0

Background: when running in laptop-mode, all writes to the disk are postponed until a scheduled disk spinup, this saves power. Only an uncached read, or an explicit fsync(), causes the disk to spun up outside of the scheduled spinups (every 10 minutes or so?).

(This is Ubuntu Hardy RC, with Firefox 3b5)

Firefox uses sqlite to save certain data (I guess including history).

This prevents laptop-mode from running effectively, since whenever Firefox records a new entry (i.e. you browse to a page), its sqlite storage calls fsync(), which in turns forces the disk to spin up. Laptop mode in general seems to be quite efficient, with Firefox being the only cause of increased spinups for me.

Sqlite does support a nosync mode, which could be enabled while in laptop-mode. IMO it would be worth to at least enable the option to lose some history in a (system) crash (which is only while in laptop-mode), if it means Firefox can be used in laptop-mode. Currently, just browsing with Firefox causes so many spinups the power savings are nil, and the Load_Cycle_Count increases way too fast.

Example:

[75250.049865] pdflush(31873): WRITE block 109142072 on dm-2

.... last write
.... then 323 seconds of disk in spun down state ..
.... then in firefox clicking a link

[75613.477491] firefox(21767): dirtied inode 4784757 (places.sqlite-journal) on dm-2
[75613.477517] firefox(21767): dirtied inode 4784757 (places.sqlite-journal) on dm-2
[75613.478586] firefox(21767): dirtied inode 4784273 (places.sqlite-stmtjrnl) on dm-2
[75613.478599] firefox(21767): dirtied inode 4784273 (places.sqlite-stmtjrnl) on dm-2
[75613.479031] firefox(21767): WRITE block 76662616 on dm-2

... and now the writing starts because of the fsync() of sqlite.

A user would expect that on a "worn-in" desktop (i.e. basically everything you use is in cache) normal web browsing should not cause a sync (or read) event for every page. Webbrowsing is probably one of the most common activities on laptops running on battery, and Firefox is the most popular webbrowser in Ubuntu.

ProblemType: Bug
Architecture: i386
Date: Wed Apr 23 14:50:56 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: nvidia
Package: firefox-3.0 3.0~b5+nobinonly-0ubuntu3
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=nl_NL.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-16-generic i686

[benjaminzsj (b3nj4m1n)]

Is this a laptop mode only problem? Mine is on AC power and has the same problem. And the disk spins even if I stay at the same pages for some time.

[Dennis Noordsij (dennis-noordsij)]

Benjamin, that's a good point. No, it is not laptop-mode only, Firefox behaves this way all the time, it's just that on AC I don't have disk power savings enabled, so I didn't look at it from that side.

[Gareth Fitzworthington (mapping-gp-deactivatedaccount)]

Upstream report:
https://bugzilla.mozilla.org/show_bug.cgi?id=421482

[Marius Gedminas (mgedmin)]

Firefox 3.0b5 in hardy issues these fsyncs so often it starts blocking on them for seconds, becoming completely nonresponsive in the UI with compiz making the whole window grey). It's not just a power-saving issue, it's a painful usability problem.

Here's a short excerpt from strace taken while I was typing this comment:

$ strace -p `pidof firefox` -e fsync -tT
Process 7187 attached - interrupt to quit
03:37:04 fsync(49) = 0 <7.587739>
03:37:11 fsync(49) = 0 <0.273196>
03:37:12 fsync(32) = 0 <0.229370>
03:37:33 fsync(49) = 0 <12.852950>
03:37:45 fsync(49) = 0 <0.184390>
03:37:46 fsync(32) = 0 <0.220538>
03:38:06 fsync(49) = 0 <5.217726>
03:38:11 fsync(49) = 0 <5.487585>
03:38:17 fsync(32) = 0 <0.464993>
03:38:37 fsync(49) = 0 <3.724943>
03:38:41 fsync(49) = 0 <5.732189>
03:38:47 fsync(32) = 0 <6.252349>
03:39:14 fsync(49) = 0 <8.729353>
03:39:22 fsync(49) = 0 <0.930190>
03:39:23 fsync(32) = 0 <0.173965>

As you can see, fsync calls block Firefox for several seconds, a few times every minute. The file handles point to places.sqlite

$ lsof -p `pidof firefox`
...
firefox 7187 mg 32uw REG 8,3 8380416 8814778 /home/mg/.mozilla/firefox/default.a83/places.sqlite
...
firefox 7187 mg 49u REG 8,3 0 1884617 /home/mg/.mozilla/firefox/default.a83/places.sqlite-journal

Note that firefox 3.0b4 (at least the one in gutsy-backports) did not have this problem, or if it did, it wasn't as noticeable.

[Marius Gedminas (mgedmin)]

Having used Firefox for a couple of days more, I can now say that the problem isn't as bad as I initially thought: Firefox in Hardy is hiccup-free most of the time.

[Félix C. Morency (colibry10)]

I can confirm this bug. The disk spins up and write for 5 to 10 sec while the browser (and the system) is (are) unresponsive.

[Félix C. Morency (colibry10)]

This bug seems related:

https://bugs.launchpad.net/firefox/+bug/215728

[Loïc (opensource-loic)]

The issue is the same on Windows version of Firefox 3b5 (Firefox Portable).
Since I'm using it from an USB drive with an activity led, I've noticed a *permanent* activity and the latest modified file is places.sqlite !

Accessing my USB drive is very slow whenever Firefox Portable is running, and sometimes it even render Firefox unresponsive since it tries to access another file on the sync-flooded drive.... I fear for the safety of my USB drive, and it's become difficult to use Firefox...

I know it's ubuntu's BTS, but I wanted to post this comment to tell you it's a Firefox bug, on every platform, not only linux ;)

[Dennis Noordsij (dennis-noordsij)]

Sorry, but this is not a duplicate. Firefox should still not force the disk to spin up every time you browse to a different page. It's nice that the high load issue is fixed as well, but the original issue of this bug report still stands - firefox makes laptop_mode unusable.

[Loïc (opensource-loic)]

Moreover, it's not urlclassifier3.sqlite but places.sqlite which is rewritten too often.
It happens even after a long time since Firefox has been started.

Maybe the whole sqlite system embedded in Firefox3 is doing this ?

[ubuntu_demon (ubuntu-demon)]

Firefox 2 has the same problem. But possibly to a lesser degree. Each time firefox goes to a new website firefox accesses the disk :
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/160513

[ubuntu_demon (ubuntu-demon)]

Analysis of the problem by Mozilla's Mike Shaver :
http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/

[Dennis Noordsij (dennis-noordsij)]

My 4 year old ibook will sit completely silent for 10-20 minutes at a time without any fan or disk activity while you browse the web.

That is the essence of my bug report. Not wether it fsyncs once on every pageview or once every minute.

[Alexander Sack (asac)]

On Tue, May 27, 2008 at 06:47:59PM -0000, Dennis Noordsij wrote:
> My 4 year old ibook will sit completely silent for 10-20 minutes at a
> time without any fan or disk activity while you browse the web.
>
> That is the essence of my bug report. Not wether it fsyncs once on every
> pageview or once every minute.
>

RC1 builds with this fix should be in hardy-proposed now

 status fixcommitted

 - Alexander

[Craig Ringer (ringerc)]

This performance regression is *exciting* when you run an LTSP thin client network. The almost constant fsync() calls and resulting I/O stalls cause users' GUIs to slow down or freeze fairly frequently.

I'm testing the update in -proposed now.

[Alexander Sack (asac)]

On Wed, Jun 04, 2008 at 05:27:36PM -0000, Craig Ringer wrote:
> This performance regression is *exciting* when you run an LTSP thin
> client network. The almost constant fsync() calls and resulting I/O
> stalls cause users' GUIs to slow down or freeze fairly frequently.
>
> I'm testing the update in -proposed now.
>

any results?

 affects ubuntu/firefox-3.0
 status incomplete

 - Alexander

[Craig Ringer (ringerc)]

I've had no reports of problems with the update from users, and the I/O stalls have gone away. It seems reasonable to attribute this to the updated firefox package.

I can certainly find no problems with the update, and it looks like it fixes the issue too. I can't be 100% sure without using something like systemtap, but it looks good.

[Craig Ringer (ringerc)]

I spoke too soon; it's still issuing storms of fsync() calls. However, perhaps due to other unrelated config changes in the server including a move to a better storage subsystem and changes in the I/O scheduler policy, I'm no longer seeing the I/O stalls.

This bug is certainly not fixed, though.

craig@tillium:~$ strace -p 16603 -e fsync -tT
Process 16603 attached - interrupt to quit
12:42:54 fsync(43) = 0 <0.041079>
12:42:54 fsync(25) = 0 <0.006983>
12:42:55 fsync(43) = 0 <0.002066>
12:42:55 fsync(25) = 0 <0.001079>
12:42:55 fsync(43) = 0 <0.001818>
12:42:55 fsync(25) = 0 <0.000879>
12:42:58 fsync(43) = 0 <0.016294>
12:42:58 fsync(25) = 0 <0.003590>
12:43:02 --- SIGCHLD (Child exited) @ 0 (0) ---
12:43:04 fsync(43) = 0 <0.010158>
12:43:04 fsync(25) = 0 <0.004260>
12:43:04 fsync(43) = 0 <0.001897>
12:43:04 fsync(25) = 0 <0.000345>
12:43:04 fsync(43) = 0 <0.001617>
12:43:04 fsync(25) = 0 <0.000607>
12:43:17 fsync(43) = 0 <0.041240>
12:43:17 fsync(25) = 0 <0.005839>
12:43:18 fsync(43) = 0 <0.020532>
12:43:18 fsync(25) = 0 <0.001234>
12:43:21 fsync(43) = 0 <0.040277>
12:43:21 fsync(25) = 0 <0.004756>
12:43:21 fsync(43) = 0 <0.007197>
12:43:21 fsync(25) = 0 <0.000355>
12:43:21 fsync(43) = 0 <0.001899>
12:43:21 fsync(25) = 0 <0.001048>
12:43:21 fsync(43) = 0 <0.002305>
12:43:21 fsync(25) = 0 <0.000700>
12:43:21 fsync(43) = 0 <0.001840>
12:43:21 fsync(25) = 0 <0.000829>
12:43:21 fsync(43) = 0 <0.001911>
12:43:21 fsync(25) = 0 <0.000352>
12:43:21 fsync(43) = 0 <0.002159>
12:43:21 fsync(25) = 0 <0.000654>
12:43:25 fsync(43) = 0 <0.051897>
12:43:25 fsync(25) = 0 <0.005379>

$ dpkg -l firefox-3.0
ii firefox-3.0 3.0+nobinonly-0ubuntu0.8.04.1

[Alexander Sack (asac)]

On Wed, Jun 18, 2008 at 04:46:19AM -0000, Craig Ringer wrote:
> I spoke too soon; it's still issuing storms of fsync() calls. However,
> perhaps due to other unrelated config changes in the server including a
> move to a better storage subsystem and changes in the I/O scheduler
> policy, I'm no longer seeing the I/O stalls.
>

fsyncs are ok unless they get too much and cause IO bustage

 - Alexander

[Cjcypoi02 (cjcypoi02)]

Added two my suggestion related to places performance, Bug 429324 and Bug 438249.
Adjusted some depending on duplicates.

[Cjcypoi02 (cjcypoi02)]

Sorry, I forgot Bug 436199

[Shaun Dennie (sdennie)]

This bug has not been fixed as per the original bug report. FF3 still causes sqlite to fsync after every page load which makes suspending disks impossible. This is tested with FF3 updated to today with proposed repository enabled.

[Motin (motin)]

Same here. Fsyncs are still issued upon browsing. Using version 3.0+nobinonly-0ubuntu0.8.04.1 :

motin@motin-laptop:~$ strace -p `pidof firefox` -e fsync -tT
Process 11272 attached - interrupt to quit
00:06:20 fsync(38) = 0 <0.013767>
00:06:40 fsync(37) = 0 <0.003164>
00:06:40 fsync(39) = 0 <0.000787>
00:06:40 fsync(33) = 0 <0.003491>
00:06:42 fsync(37) = 0 <0.003133>
00:06:42 fsync(33) = 0 <0.003086>
00:06:42 fsync(37) = 0 <0.002688>
00:06:42 fsync(33) = 0 <0.000831>
00:06:42 fsync(37) = 0 <0.002788>
00:06:42 fsync(33) = 0 <0.001259>
00:06:50 fsync(84) = 0 <0.002727>
00:06:50 fsync(85) = 0 <0.000766>
00:06:50 fsync(32) = 0 <0.002414>
00:06:54 fsync(37) = 0 <0.004228>
00:06:54 fsync(33) = 0 <0.004684>
00:07:01 fsync(37) = 0 <0.037371>
00:07:01 fsync(33) = 0 <0.003869>
00:09:58 fsync(37) = 0 <0.004612>
00:09:58 fsync(33) = 0 <0.003342>
00:10:05 fsync(37) = 0 <0.004900>
00:10:05 fsync(33) = 0 <0.002296>
00:10:05 fsync(37) = 0 <0.002561>
00:10:05 fsync(33) = 0 <0.001017>

The last 6 fsyncs were issued after visiting a single page.

What is needed for this bug report to go from "Incomplete" to "Confirmed" and when is it likely that we will see "Fix Released"?

Is there any work around available until an official fix is avaiable?

[travis.detert (travis-detert)]

I thought Firefox wasn't going to be released with this problem? I'm pretty much at the point where I've lost all faith in what use to be my absolute favorite application.

Opera is looking pretty good these days. I guess I'm just going to give that my attention now, because firefox is unusable on every linux machine I have at this point.

Please, please please, someone fix this. I can't even test my site with firefox anymore it's become so slow and unresponsive. Combining that with eclipse makes for many "Hulk Angry" moments.

[Motin (motin)]

This bug is still evident in 3.0.1+build1+nobinonly-0ubuntu0.8.04.2

Sample output when browsing around 5-6 pages:

$ strace -p `pidof firefox` -e fsync -tT
Process 17527 attached - interrupt to quit
14:52:10 fsync(37) = 0 <0.003523>
14:52:10 fsync(33) = 0 <0.000982>
14:52:10 fsync(37) = 0 <0.000466>
14:52:10 fsync(37) = 0 <0.000814>
14:52:10 fsync(33) = 0 <0.000643>
14:52:10 fsync(37) = 0 <0.000430>
14:52:45 fsync(79) = 0 <0.001523>
14:52:45 fsync(83) = 0 <0.000348>
14:52:45 fsync(124) = 0 <0.000849>
14:52:58 fsync(37) = 0 <0.002234>
14:52:58 fsync(33) = 0 <0.004564>
14:52:58 fsync(37) = 0 <0.000576>
14:53:06 fsync(37) = 0 <0.042619>
14:53:06 fsync(33) = 0 <0.002139>
14:53:06 fsync(37) = 0 <0.000348>
14:53:06 fsync(37) = 0 <0.000409>
14:53:06 fsync(33) = 0 <0.000318>
14:53:06 fsync(37) = 0 <0.000306>
14:53:06 fsync(37) = 0 <0.000376>
14:53:06 fsync(33) = 0 <0.000433>
14:53:06 fsync(37) = 0 <0.000319>
14:53:13 fsync(37) = 0 <0.003026>
14:53:13 fsync(33) = 0 <0.001112>
14:53:13 fsync(37) = 0 <0.000328>
14:53:13 fsync(37) = 0 <0.000392>
14:53:13 fsync(33) = 0 <0.000373>
14:53:13 fsync(37) = 0 <0.000250>
14:53:15 fsync(37) = 0 <0.002996>
14:53:15 fsync(33) = 0 <0.004490>
14:53:15 fsync(37) = 0 <0.000468>

Also, the toolkit.storage.synchronous setting (mentioned in the upstreams bug report) which should be available in > rc2 is not to be found.

When do we think that fixed ubuntu packages are available?

Btw @travis.detert: I don't believe that this bug is going to fix your unusability issues you are describing. This bug only affects battery and hard drive life when trying to save power...

[Dara Adib (daradib)]

Does the bug still exist?

[Alexander Sack (asac)]

On Thu, Aug 07, 2008 at 02:24:11PM -0000, Dara Adib wrote:
> Does the bug still exist?
>

I think it still exists - though much less intrusive than when 3.0b5
came out.

 - Alexander

[Dara Adib (daradib)]

Reverting to confirmed status as the bug still exists.

[SteveHiggins (asaninehuman)]

Using Firefox 3.0.1 on Ubuntu 8.04.1 i386 and the problem is still there.
This is on my desktop system.

[SteveHiggins (asaninehuman)]

Just to add that I disabled the 'attack sites' and 'forgery sites' checks and the disk activity stopped.

[Alexander Sack (asac)]

On Tue, Sep 02, 2008 at 10:54:36AM -0000, SteveHiggins wrote:
> Just to add that I disabled the 'attack sites' and 'forgery sites'
> checks and the disk activity stopped.
>

How much load do you see?

What system specs do you have?

 - Alexander

[Christian Gogolin (cgogolin-deactivatedaccount)]

I have the exact same problem with iceweasel 3.0.3 under debian lenny (package version 3.0.3-2)

[Alexander Sack (asac)]

moving to meta places bug. places is known to cause sqlite usage which triggeres IO.

[Rachel Greenham (rachel-strangenoises)]

Bump. Bug continues to exist in Intrepid. It's not so much that the performance is bad, but that with laptop mode on it causes hard drive spinups on every page hit, which defeats the purpose of laptop mode.

[Jose Bernardo (bernardo-bandos)]

The performance hit is awful if you're running intrepid/firefox on a netbook (in my case a aspire one) with a SSD drive. 2-3 seconds at least of pauses for every page that firefox opens.

[Rachel Greenham (rachel-strangenoises)]

i made a workaround for myself with a maze of scripts that means the firefox profile resides entirely in a tmpfs mount, symlinked from my ~/.mozilla/firefox. It works, and i only lose data if i shutdown or crash between cron-rsyncs of that profile back to the drive, but it's pretty unsatisfactory really - only rather more satisfactory than the default behaviour.

[huiii (a00ps)]

i am having this issue, too.
firefox 3 spins up my hard-drive.
battery life short when browsing..
mmh..
global warming

[amn (armencho)]

People, I suggest someone (yes, that includes me too) start a patchwork. One that does not use fsyncs, substituting them with either database synchronization as an option or inventing a solution where Firefox is still usable without the need to read or write from harddrive every time user opens a page.

I am going to download the source and start poking into it. If open source is what it promises to be (and I am a programmer), it should not be impossible to solve this, and at least get more battery life and laptop thermals in reward.

[Alexander Sack (asac)]

Jose Bernardo wrote:
> The performance hit is awful if you're running intrepid/firefox on a
> netbook (in my case a aspire one) with a SSD drive. 2-3 seconds at least
> of pauses for every page that firefox opens.
>
>
what filesystem is that? ext3?

[Alexander Sack (asac)]

amn wrote:
> People, I suggest someone (yes, that includes me too) start a patchwork.
> One that does not use fsyncs, substituting them with either database
> synchronization as an option or inventing a solution where Firefox is
> still usable without the need to read or write from harddrive every time
> user opens a page.
>
> I am going to download the source and start poking into it. If open
> source is what it promises to be (and I am a programmer), it should not
> be impossible to solve this, and at least get more battery life and
> laptop thermals in reward.
>
>
upstream put a lot of efforts into this and tuned this quiet much so far
... probably more to come sooner or later ... however, they say its ext3
filesystem that causes the real issue here - of course, not really
helpful. You could setup a test system with a different fs though to
check if its better.

[Jose Bernardo (bernardo-bandos)]

ext2, noatime
I know the AA1 SSD is one of the slowest, but still, FF2 worked well here. With FF3 I have sometimes minutes where it won't answer and the ssd light will stay on, something I never had with FF2.

[Thomas R. N. Jansson (tjansson)]

I am still experiencing this problem on my Lenovo Thinkpad X200. When I am on battery the the disk spins down but every time I open a new page the disk spins up and writes something to the disk which locks firefox for 2-3 seconds.

I have started to use Opera when on battery just to avoid it. There ought to be a option in Firefox whether or not cared for smart history and that. I for one don't care I would much rather use a responsive Firefox than a fancy-pancy Firefox.

[Rnicoletto (rnicoletto)]

You should add Bug 427521 to the list.

[Philip Neustrom (philipn)]

I can confirm this is still occuring with FF 3.5 in Ubuntu on a Thinkpad x200s.

Every new location causes FF to write to disk. lm-profiler clearly shows this. I tried compiling firefox to have:

PRAGMA default_synchronous='0';

after each sqlite3_open() in the code, but I think I screwed something up. I ended up just putting my profile on a tmpfs which solves the problem (but this is not a fix).

I think setting the default_synchronous to zero would solve the problem, though. I'm not sure what additional issues this would cause, but losing my places.sql because my machine crashes is definitely not a concern -- losing my hard disk (and all my data on it) because it's spinning up and down too quickly is :)

[Hans van den Bogert (hbogert)]

there is a fix committed on 2009-08-28, but this is for firefox-3.0, what is the status on the issue icw firefox-3.5 ?

[Philip Neustrom (philipn)]

I am still seeing this in 3.5. It was responsible for the death -- within 2
months -- of my brand new laptop hard disk.

On Oct 21, 2009 4:01 PM, "dlgandalf" <email address hidden> wrote:

there is a fix committed on 2009-08-28, but this is for firefox-3.0,
what is the status on the issue icw firefox-3.5 ?

-- Firefox keeps forcing disk to spin up when browsing because its sqlite
storage calls fsync() fo...

[Hans van den Bogert (hbogert)]

yeah I know, but this is one big ass regression which shouldn't be too hard fix considering they do know the fix right?

[Martin Emrich (emme)]

Marking this as affecting firefox-3.5, as I, too, see this on karmic with Firefox 3.5. As several people wrote that it affects them, I set it to "confirmed" right away.

[Gervase Markham (gerv-mozilla)]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body contains places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv

[Soenke (s0enke)]

I can confirm this behavior on karmic amd64 with latest firefox (3.5.7+nobinonly-0ubuntu0.9.10.1):

soenke@kellerautomat:~$ strace -p $(pgrep firefox) -e fsync,fdatasync -tT
Process 20808 attached - interrupt to quit
23:21:47 fsync(71) = 0 <0.035733>
23:21:57 fsync(94) = 0 <0.059098>
23:22:07 fsync(94) = 0 <0.033586>
23:22:17 fsync(69) = 0 <0.046717>
23:22:28 fsync(69) = 0 <0.052431>
23:22:38 fsync(66) = 0 <0.033899>
23:22:45 fdatasync(74) = 0 <0.061717>
23:22:45 fdatasync(74) = 0 <0.055044>
23:22:45 fdatasync(34) = 0 <0.066163>
23:22:48 fsync(94) = 0 <0.044252>
23:22:58 fsync(94) = 0 <0.063860>
23:23:16 fsync(94) = 0 <0.035658>
23:23:22 fdatasync(74) = 0 <0.049499>
23:23:22 fdatasync(74) = 0 <0.044065>
23:23:22 fdatasync(34) = 0 <0.066276>
23:23:26 fsync(63) = 0 <0.045178>
23:23:36 fsync(63) = 0 <0.071344>

fds 34 and 74 are places.sqlite[-journal]:

This is how it looks like when using firefox as usual.

Often I even recognize fsync fireworks (I had just to wait about 10 minutes for this report):

23:31:51 fdatasync(74) = 0 <0.043869>
23:31:51 fdatasync(34) = 0 <0.077413>
23:31:51 fdatasync(74) = 0 <0.058513>
23:31:51 fdatasync(74) = 0 <0.044234>
23:31:51 fdatasync(34) = 0 <0.066308>
23:31:51 fdatasync(74) = 0 <0.071748>
23:31:51 fdatasync(74) = 0 <0.047007>
23:31:51 fdatasync(34) = 0 <0.077155>
23:31:51 fdatasync(74) = 0 <0.043521>
23:31:51 fdatasync(74) = 0 <0.055024>
23:31:51 fdatasync(34) = 0 <0.066442>
23:31:53 fdatasync(74) = 0 <0.050449>
23:31:53 fdatasync(74) = 0 <0.044038>
23:31:53 fdatasync(34) = 0 <0.108065>
23:31:53 fdatasync(74) = 0 <0.056989>
23:31:53 fdatasync(74) = 0 <0.054972>
23:31:53 fdatasync(34) = 0 <0.088218>
23:31:53 fdatasync(74) = 0 <0.061579>
23:31:53 fdatasync(74) = 0 <0.046760>
23:31:53 fdatasync(34) = 0 <0.071646>

and so on for about 5-10 seconds. This behavior is annoying especially if you have an ecryptfs homedir :(

[Mak77 (mak77)]

This bug has lost most of the interest, indeed it has not been updated from 2009 and most of the reported issues have been fixed.
It's actually easier to search for Places bugs with "perf" specified in the keywords, that is the suggested way to track these bugs.