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.
Post a Comment
Member since:
2006-01-04
http://lwn.net/Articles/330150/
(well, at least for Intel)
Member since:
2006-04-18
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.
Member since:2006-01-06
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
Member since:2005-07-11
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.
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.
Member since:2005-07-06
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.
Member since:2007-09-22
Member since:
2006-10-01
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.
Member since:
2007-04-13
Member since:2008-08-19
Member since:2007-09-22
They are working on it:
http://lwn.net/Articles/299483/
Member since:
2007-02-17
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
Member since:2005-07-07
Member since:2007-02-17
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