Submitted by A number of significant opportunities for performance improvements seem to be just over the horizon for Linux systems. OSNews regular lemur2 submitted an overview of the most important potential performance improvements to us.
One of the most popular freedom software programs in the world got a major boost this week. GCC 4.4 adds in lots of new features, the biggest of which is the Graphite Framework. There are a number of new command line switches that provide better optimization. Any improvements in compiler optimisations have potential to achieve performance gains for a vast array of software.
The long-standing latency issues with the Linux ext3 filesystem, which most famously manifested itself as the much-lamented Firefox system-freeze problem, might be finally cured by fixes which are due for inclusion in the upcoming Linux 2.6.30 kernel.
On a related note, the patches adopted in Linux 2.6.30 introduce many significant changes affecting data security and Ext3 and Ext4 performance. Support for the EXOFS and NILFS2 file systems is new, as is the cache for the AFS and NFS network file systems.
http://lwn.net/Articles/330150/
(well, at least for Intel)
While it’s noble that ext3 is still kicking along and compatible with ext2, they have to do something about the fsck times. I have some large volumes (xxxGB and 1TB) and it takes *hours* (over a FC SAN) to fsck if the system crashes or if the 180 days is reached. That’s just freaking unacceptable.
Yes, I could break stuff up but then I just end up running out a space on one volume when the users fill up a directory I didn’t expect. Yes, I could use another file system (like what? Reiser is semi-dead, XFS is great but who knows how long it’ll be supported, and RHEL doesn’t support either anyways).
Great:
“Faster file system checking
In ext4, unallocated block groups and sections of the inode table are marked as such. This enables e2fsck to skip them entirely on a check and greatly reduce the time it takes to check a file system of the size ext4 is built to support. This feature is implemented in version 2.6.24 of the Linux kernel.”
So what happens when the file system is fairly full? I bet it has to check everything and takes ages.
Definitely. Where I used to work we had 1TB arrays built out of 120GB drives. At the time reiserfs was the only one that worked acceptably with 2 levels of checking, the first one (fix fixable) being very fast.
Fast forward to today (last year) with 16 drive 1TB raid6…still reiserfs. XFS & JFS during deployment both blew entire arrays (non recoverable errors, processing runnung days at a time). Not much to do about that area which had lots of new construction. reiserfs3 still is the best choice.
Edited 2009-04-29 13:16 UTC
ext3 was never meant to be used on large filesystems. Other filesystems like JFS and XFS were. Using ext3 on anything larger than about 500 GB or so is just painful.
We stopped using ext3 for anything except /boot many, many, many years ago.
XFS is where it’s at when it comes to multi-TB filesystems. There were issues in the past with possible data loss during a power outage (everyone has a UPS on their server, right, configured to do an ordered shutdown?), but I believe those have been fixed for over a year now.
Looking at the filesystem landscape for Linux, it seems XFS and ext4 will be king until btrfs or zfs becomes available/production-ready.
Yer, that’s the general consensus from everyone who uses ext3 – don’t use it for large filesystems and certainly not if you have large multi-gigabyte files you are handling. It’s really painful.
I’m certainly not interested in ext4 in the slightest because it has come to the end of its life. They seem to be trying to solve some problems for these workloads that JFS and certainly XFS solved years ago, and repeating the same mistakes that XFS got criticised for and solved years ago.
While I’m not jumping up and down saying “I need btrfs now otherwise I’ll die or move to Solaris and ZFS!” it’s certainly the only logical progression as regards filesystem improvement.
That’s one of the reasons ext4 exists, faster checking, better support for really large disks, etc.
Man I get the Led out at least once a week on my Linux system. Some Kashmir or some Stairway…
Wait… that isn’t what you meant?
The filesystem stuff is great, I’ve been working on HPC loads collecting trace data and those things get upto 120 GB. EXT4 has been great in this regard, I’m guessing that is the work of extends and multiblock allocation.
Not sure I’m so enthused about the GCC improvements. I’ve really not noticed compiler optimization imporovements to be really helpful. Unless you are fixing braindead regressions. Like what GCC does to the stack at -O0. Graphite could be interesting, my understanding is that graphite should eventually lead to auto parallelization.
Honestly I think that the last major frontier for Linux performance is in the 3d drivers. Get those fixed up and Linux should be golden performance wise.
Why couldn’t they adopt BeOS’s speed on boot?
Can you point to the code they’d need to copy to adopt that?
They are working on it:
http://lwn.net/Articles/299483/
Apart from speed improvements in the GCC compiler, and removal of significant speed blocks in the ext3 filesystem, another important speed increase could possibly be coming soon (not uniquely to Linux desktops) in the form of Firefox 3.5.
No more betas for Firefox 3.5: Browser on track for Q2 launch
http://www.tgdaily.com/html_tmp/content-view-42215-140.html
Edited 2009-04-30 09:41 UTC
Ah, while at it, mention Chrome. I never tried it before yesterday (on windows) but I’m still impressed. Darn, that thing is insanely fast! IE is pathetic, and even firefox doesn’t come close…
Not ready yet.
http://www.downloadsquad.com/2009/03/17/google-chrome-on-linux-prog…
At least, it is not yet ready to be a factor in any potential speed up of the Linux desktop.
Also, given the status of Chrome with respect to extensions, wouldn’t I also have to run it through a proxy like this one?
http://lifehacker.com/5046529/how-to-block-ads-in-google-chrome
http://en.wikipedia.org/wiki/Privoxy
Edited 2009-05-01 01:22 UTC