Linked by Thom Holwerda on Wed 29th Apr 2009 08:24 UTC, submitted by lemur2
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.
Thread beginning with comment 360920
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
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
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.
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:
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.