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...
Alright, I'm going to start calling people on HN about this pet peeve of mine:
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.
data=ordered certainly does have significant performance problems. Most notably, it causes fsync() to actually act like sync(), so flushing a single file to disk can potentially cause a flush of the entire disk buffer instead!
That behavior for fsync() is permitted by POSIX (and incidentally matches a permitted, but not required, interpretation of sync()). It's also something that, given reasonable application design, should rarely be an issue.
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.
Browsers are CPU-bound, network-bound, GPU-bound, memory-bound (esp. memory bandwidth, though some people count that as "CPU"), and filesystem-bound. Depending on exactly what you're doing with the browser.
I would agree that calling ext3 obsolete is odd, but I don't know enough about the particulars of file system performance to understand why data=ordered is or is not problematic. This leads to the interesting problem of judging the opinion of several contradicting, but apparently similarly qualified people. I'm sure someone on HN is able to decisively explain: can someone do so?
Originally, ext3 filesystems maintained journals of all metadata and data changes. This substantially decreases the likelihood of the filesystem ending up in an irrecoverably inconsistent state, but it also has major performance implications.
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.
Not quite, though that's part of what the problem was. There's a mechanism (fsync) for forcing the changes in a particular file to be written to disk. As a result of the consistency guarantees made by the "data=ordered" mode, synchronizing a single file often forces the filesystem to make other, unrelated writes to the disk as well. In the worst case the entire cache can be forced to disk. The end result is substantially more disk activity than would be expected.
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...
Not an opinion about ext3, but "I have many machines using it" does not mean a system is obsolete or not, for obvious reasons. Besides, with companies still running COBOL/FORTRAN software on decades old hardware, what is "obsolete"?
Exactly, and both JFS and XFS are still maintained as well. In fact, this is where all file systems should strive to get: stable releases with bug fixes only.
The problem with data=ordered is that it imposes a global order, allowing one I/O stream to stall others. Imagine if waiting for data to be acknowleged on one TCP socket meant waiting for all data sent earlier on all sockets - even those to slower peers - to be acknowledged as well. That's completely FUBAR, but it's basically what fsync with data=ordered does to an entire filesystem. There are hundreds of performance reports showing this effect, and nobody cares if one user's I/O patterns are too lame for them to have noticed.
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.
Calling it obsolete is hyperbole. A standard definition of obsolete is something that was once common but no longer is. Just last week I had to revert a number of ext4 filesystems back to ext3 due to performance problems on RHEL5, so I'm afraid that ext3 will be in common use for years to come.
(The performance problems aren't present in Fedora 16, so you could argue that RHEL5 is obsolete.)
Yes, the RHEL5 kernel is obsolete in that it lacks the barrier support necessary to implement proper behavior with decent performance. The fact that obsolete ext3 runs better on also-obsolete 2.6.18 kernels doesn't really tell us much except that sometimes two pieces of software evolve together, and sometimes versions that were developed together work better than versions that were not.
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...