Linked by Thom Holwerda on Wed 3rd Dec 2008 20:42 UTC, submitted by Michael
Thread beginning with comment 339106
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
More News »
Sponsored Links



Member since:
2005-07-24
The disk i/o benchmarks were certainly interesting, and worth reading the article to see. But when they started throwing lzma, bzip2, lame, video games, and other processor bound "benchmarks" at these filesystems, I went... "what"? They could have made something out of the video game benchmarks, maybe, by checking the time to start the game and load a level, rather than reporting the FPS. If the FPS is affected by the filesystem, its time to find a new gaming house, not a new filesystem!
Looks like ext4 closes the gap with XFS, or now beats it significantly, in all but that surprising 4GB random delete phase. Deletes used to be a real Achilles heal for XFS, and I know the Linux XFS devs put a lot of special effort into improving that situation. But since it is also slower than ext3 in this phase, I suspect something else is going on.
Beating XFS by 25-30% on the 8GB sequential read and 4GB sequential create phases is particularly notable, since large sequential reads and writes were major design goals for XFS.
And all that with the significant additional integrity guarantees that the default "data=ordered" mode (and, I believe, journal checksumming) provides over XFS. Impressive work by the ext4 guys, indeed.
Edited 2008-12-03 23:48 UTC