Good news: Mozilla fixed their damn browser
jasonlefkowitz.net
jasonlefkowitz.net
That is, his machine is configured to use an obsolete filesystem (ext3) in a mode with significant performance problems (data=ordered).
There are numerous ways that a machine can be mis-configured such that it suffers from poor performance. It would be better if Firefox detected these and warned about them, rather than just silently working around the broken-ness.
As it happens, neither is ext3 an obsolete filesystem (I have many machines using it just fine, thank you, with no intention to migrate to less tested filesystems just because they're "new"), nor "data=ordered" has significant performance problems.
More amusing than this just the fact that the filesystem is a bottleneck for a web browser... an application that should be network and CPU bound...
Please stop 'finding it amusing' when you disagree with people. It makes you sound arrogant and passive-aggressive. Even if the other side is totally wrong, hammering that fact in is rhetorically counter-productive.
Part of Firefox's problem was that practically everything a user would do resulted in fsync() being called -- that's unnecessary and unreasonable. It's one thing to fsync() when one adds a bookmark, or saves a password. Doing it every time a link is clicked is just insane, and would pose a performance problem regardless of ext3's eccentricities.
On ext3 it can take 20 minutes to delete a file that in ext4 is deleted in a few seconds. That is including a followup "sync".
It is an obsolete filesystem.
Relatively early on ext3 was extended with "data=ordered" and "data=writeback" modes (with "data=ordered" being the default and recommended mode, as "data=writeback" is marginally faster but offers few consistency guarantees). In these modes only metadata changes are committed to the journal.
In "data=ordered" mode the filesystem attempts to guarantee that data will actually be written to the disk (not merely cached) before any related metadata writes occur, as opposed to caching and writing all data according to an outside schedule. Obviously, this also has certain implications for write performance.
I would say that Firefox was incontrovertibly broken in this case, but my views on the adoption of ext4 would probably be considered rather conservative. Regardless, ext3 isn't going away any time soon so this fix will be appreciated.
It's certainly not obsolete as in "you shouldn't use it anymore", but it certainly is as in "there is really no reason to continue using it". While moving to BtrFS may be premature for most people, not moving to ext4 is somewhat eccentric. Ext4 is more than good enough.
> More amusing than this just the fact that the filesystem is a bottleneck for a web browser...
Indeed.
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Fl...
The problem is that, in ext3, not using data=ordered is also problematic - this time in terms of potential corruption and security issues. That's why even the people who brought you ext3 abandoned it years ago in favor of making ext4 do these things the right way. If you want reasonable fsync behavior, plus niceties like block-size awareness and trim/discard support, you need to use a modern filesystem.
A piece of software that embodies a broken approach to a solved problem is by definition obsolete, and that includes ext3. Please don't make claims about what's obsolete when you don't even understand the issues that would make it so.
(The performance problems aren't present in Fedora 16, so you could argue that RHEL5 is obsolete.)
Some notable ones that were fixed recently include http://bugzil.la/690354 and http://bugzil.la/686025
The only problem are some less common plugins, but adblock and firebug get updated within days... and I just switch to the latest official release for quake live.
Likewise. I also have several extensions enabled and generally have 30+ tabs open all the time, sometimes many times that. I have had an odd crash but very rarely.
The main issue with "data=ordered" is not that it imposes a global order, but that if you do block allocations, fsync() requires a journal commit, and the security guarantees behind "data=ordered" require that all newly allocated blocks must be written out before the filesystem-wide journal commit can be allowed to complete. (Ext4 doesn't have this problem because it uses delayed allocation.)
This isn't an issue with other databases such as Oracle, DB2, MySQL, etc. They have no problems running on ext3. This is partially because they don't use fsync() at all. Oracle and DB2 use O_DIRECT to blocks that are allocated once (new blocks are only allocated when the table space file needs to be grown), and MySQL uses fdatasync() to files that aren't constantly being created and destroyed. SqlLite, because it is trying to pretend that it only needs one file, uses many, MANY temporary files which are being constantly created and destroyed. This is not efficient, and is why SQLite has all of these problems, but millions and millions of dollars worth of enterprise servers can use ext3 running on RHEL3, RHEL4, and RHEL5 on Oracle without hitting these issues.
The sad thing is most people like to use SQLite because it doesn't require manual scheme generation, not because it only uses one file. (In fact it doesn't; there are multiple temporary files, some of such must be there in case of an unclean shutdown. So if you copy just the single file after a program crash, you'll screw up the database.) If someone created a lightweight database that uses SQLite's interfaces, but used a single directory to hold all of the database's files, and then didn't constantly copy data back and forth between temporary files which were being constantly created and destroyed, but instead used the storage strategies used by the more sophisticated database systems, the result would work well on ext3, and for all file systems, it would use less data writes, which would save battery usage, SSD write endurance, and many other things. The last time I measured it, Firefox's "awesome bar" was consuming a third of a megabyte of write bandwidth to the disk per click; and it was updating at most a few hundred bytes of data. The rest was all overhead due to the catastrophic inefficiencies of SQLite.
P.S. And if you do implement this, please consider releasing it under the Apache license so I can hopefully convince the Android team to drop SQLite in favor of something that was a bit more written towards performance --- and Android users all over the world will thank you. :-)
I ran Google Chrome open with 80-100 tabs for 3 WEEKS without anything going wrong. Sunday the 18th I finally closed it and restarted my computer (after 3 weeks of non stop running).
Monday I launched the latest build of FireFox and within 30 minutes it crashed. It then crashed again a few hours later.
Goodbye FireFox.
It's still my main browser but this one issue just kills the entire experience.
Damn. Oh and this is my 3rd post.
(assuming you created someotherprofile via Profile Manager - it's dead easy)
(Works on Windows, too)
edit: I'll note that I don't believe that the parent to this post should be down-voted. It was informative and on-topic.