Comment 82 for bug 215728

I described my own experience in reply to Lars, here's what I said. BTW, I am on RPM-based Mandriva-2008-fall (2008.0) so it's not explusive to Ubuntu (Probably no one imagines that it was, but I'll document that fact right here.)
I said,

- - - quote form Mozillazine - - - -

"This seems to be a 100% Firefox-Created issue, although increased A/V activity may be a side effect of the FF misbehavior on your box.

"Many times when I start running FF3, my hard drive will busy for a long time doing something. Usually it's shortly after starting FF3, but sometimes it goes wild in the middle of a long session. CPU does go 100%-- and my system has no virus scanner or add-on malware monitor at all, modern Linux doesn't need one in my kind of usage. (The entire Firefox installation is within a USER account, and nothing has access anywhere in a system context.) Within Firefox, the panel becomes totally unresponsive. I can start other applications, because Linux is a bit more "fair" about allowing other applications (like my Window Manager) to get a peice of the box when I do something-- but inside Firefox, it's totally locked up and focused on this disk-thrashing task for many, many seconds.

Lars, are you using a really old and much-upgraded Profile? (I am, I've got about a zillion sets of "saved form" data and don't know how to migrate this info to a freshly-built profile.)

I did get rid of urlcalssifier2.sqlite a couple of weeks ago, but the current urlclassifier3.sqlite has already grown to considerable size. I don't know if FF might be churning the whole file, in tiny random-access reads, to "organize it". If so, that needs to be STOPPED. There's also a tiny chance that it's the new memory model doing some garbage collection, but I doubt this, because it happens right at startup a lot, before any memory bits have been allocated. Also, I have lots of RAM, and the Firefox task can get all the "real" memory it wants to have. Here's my current sqlite file sizes:

-rw-r--r-- 1 rick rick 1082368 2006-04-30 00:00 bookmarks_history.sqlite
-rw-r--r-- 1 rick rick 7168 2008-03-24 01:37 content-prefs.sqlite
-rw-r--r-- 1 rick rick 193536 2008-04-28 10:53 cookies.sqlite
-rw-r--r-- 1 rick rick 12288 2008-04-28 10:28 downloads.sqlite
-rw-r--r-- 1 rick rick 240640 2008-04-28 10:39 formhistory.sqlite
-rw-r--r-- 1 rick rick 5120 2007-12-12 12:16 permissions.sqlite
-rw-r--r-- 1 rick rick 4685824 2008-04-28 10:53 places.sqlite
-rw-r--r-- 1 rick rick 2048 2007-10-16 01:11 search.sqlite
-rw-r--r-- 1 rick rick 32229376 2008-04-28 10:40 urlclassifier3.sqlite
-rw-r--r-- 1 rick rick 2048 2008-04-18 09:37 webappsstore.sqlite

I'm currently running a 5-day old version,
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008042320 Minefield/3.0pre - Build ID: 2008042320

I've no idea what it's doing, and haven't opened a bug because I've no idea how to describe it adequately-- this was pretty much everything I know."

- - - - end mozillazine quote - - - - -

But my "Firefox locked up, disk thrashing" Time periods often exceed 20 seconds, and lots of people have less capable boxes than I do (disk has 8mb cache, lots of people still have just 2mb). I agree with comment 9-- this problem wasn't present until some time around March. Unfortunately, I can't provide the legwork to determine a regression window for it's appearance.