Posted May 29, 2008 14:12 UTC (Thu) by drfickle (guest, #1093)
Parent article: In defense of Firefox
I'm using Fedora 9 at home and have yet to encounter this behavior. What does it take to
trigger it? 20 tabs? Limited memory/swap?
So far I don't have any complaints about FF3. However, like our editor, I am still waiting for
the "awesome" to kick in.
Posted May 29, 2008 14:52 UTC (Thu) by felixfix (subscriber, #242)
[Link]
I believe you have to have some other process(es) with heavy disk I/O, so when ff3 fsync()s,
it also fsync()s all disk I/O, not just its own. I have had it when surfing while a compile
is running, and it is awful.
ext3 fsync is the real issue
Posted May 30, 2008 7:41 UTC (Fri) by Cato (subscriber, #7643)
[Link]
The real issue for me is that ext3 has a broken implementation of fsync() - since fsync is a
file based operation there's no excuse for syncing *all other files on the filesystem*.
Having said that, I think FF3 or sqlite could equally have used O_SYNC on write, which has
lower performance in the single file case but far better performance when other files need
syncing with fsync().
ext3 fsync is the real issue
Posted May 30, 2008 17:05 UTC (Fri) by nlucas (subscriber, #33793)
[Link]
The SQLite main developer has already tried to make sqlite to use O_SYNC instead of fsync. The
performance dropped to half.
In defense of Firefox
Posted Jun 2, 2008 20:18 UTC (Mon) by jch (guest, #51929)
[Link]
> I'm using Fedora 9 at home and have yet to encounter this behavior. What does it take to
trigger it?
The issue is that Firefox will perform large numbers of fsync system calls on files in
~/.mozilla, and fsync is implemented as a global sync on journaled filesystems.
One way to reproduce the slowdown is to put ~/.mozilla on an ext3 filesystem which has heavy
unrelated write traffic. Another is to put it on a busy NFS filesystem (having home on NFS is
rather common in academic settings).