Slashdot Mirror
Linux Filesystems Benchmarked
smatt-man writes "Over at Linux Gazette they ran some tests on popular Linux filesystems (ext2, ext3, jfs, reiserfs, xfs) and the results may surprise you."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
The original article
I support the Center for Consumer Freedom
Not quite what I got from it. Ext2 was certainly faster for a lot of operations, but is, of course, not journalled. XFS and JFS were fast, but most importantly, when it came to large files, these two tended to really take the lead. XFS was particularly good at handling large files. Overall Ext3 was disappointingly slow surprisingly often.
Jedidiah.
Craft Beer Programming T-shirts
http://209.81.41.149/~jpiszcz/index.html
:)
it's not slashdotted yet
Ext3 provides a safe low-pain entry into the world of journaled file systems. No need to re-partition or reformat. It offers reasonably good performance plus the benefits of journalling.
Obviously (as you point out) a journallying filesystem is what you need. I went for Ext3 on my Debian servers. I/O throughput wasn't so important. The good thing about Ext3 is its backwards-compatibility with Ext2. If there's a problem and you don't have all the kernel modules or tools then you're still pretty much guarranteed access to the file system by mounting it as Ext2 as support for that system is almost universal under Linux.
No, in fact ext3 is one of the few that actually will journal data as well as metadata.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Here's a mirror of the article:l
http://www.gutenpress.org/links/LG/102/piszcz.htm
RFC2119
PNGs are smaller than GIFs, better compression, etc. (if you use same color-depth (8 bit)).
Move Sig. For great justice.
>Web site accessibility (use image type supported by all major browsers)
All the "good features" of GIF is supported by PNG in all current browsers. You'd have to go back in time fem years to find a browser that can't display a basic PNG. If you think otherwise, give me a link to one that matters that doesn't, and explain to me why, if it wasn't released/updated this year, using it isn't a security issue.
Since GIF doesn't support per-pixel-alpha to begin with, you lose nothing by using PNG for everything. After all, with GIF you didn't have the choice at all so there is no issue with simply "converting to PNG".
Score: PNG
>Bandwidth conservation
PNGs are always smaller where it matters (anything more complex than 1x1x1-images). In some not atypical cases a PNG can be 25% smaller than the corresponding GIF.
Score: PNG
PS. GIF-via-LZW is still encumbered in many countries.
More features, better standard, solid software, no licensing issues, smaller output == Winner: PNG
Belief is the currency of delusion.
name a "major browser" that won't support PNG. I don't know one. I use all PNG and have checked all my pages in enough "major" browsers to cover probably greater than 99% of people and they display fine.
There are options, or settings, that you can do for ext3, the default is slower, but it saves your data. Ext3 not only journals metadata, like XFS, etc... but it also journals data, which is the only filesystem that does that, if I understand this correctly.
/etc/fstab and reboot, no big deal.
"data=writeback" mode does no data journaling, only metadata journaling, and you would probably see better performance here. Although, you could lose data in the event of a power outage (no fun). Same thing applies to XFS, JFS - you could lose data because only metadata is being journaled, not real data.
"data=ordered" mode - inbetween, still no data journalling, but there are provisions that make it less likely to lose data in the case of a power problem. It has something to do with the way it journals the metadata and the way the filesystem interacts with the disk that makes is a little slower than data=writeback but also a little more secure than data=writeback if you get a power outage.
"data=journal" mode - this journals data and metadata, and with the exception of a few situations, is the slowest. The least likely to lose your data, but also much slower.
I am assuming, or at least it looks like, these tests were run with the default data=journal - so to be fair, they should have been run in data=writeback, or maybe even all three modes. Again, all you have to is specify in
It would probably be better to compare the ext3 in data=writeback mode.
IE is still too stupid to properly do an alpha channeled PNG. But it does do 1-bit, GIF-style transparency and displays generic, non-transparent PNGs just fine. And so the only place left to use GIF for is crummy animations.
Ita erat quando hic adveni.
I did a bunch of tests like this, but in 2.6 instead of 2.4. My conclusions:
* Ext2 is still overall the fastest but I think the margin is small enough that a journal is well worth it
* Ext3, ReiserFS, and XFS all perform similarly and almost up to ext2 except:
o XFS takes an abnormally long time to do a large rm even though it is very fast at a kernel `make clean`
o ReiserFS is significantly slower at the second make (from ccache)
* JFS is fairly slow overall
* Reiser4 is exceptionally fast at synthetic benchmarks like copying the system and untaring, but is very slow at the real-world debootstrap and kernel compiles.
* Though I didn't benchmark it, ReiserFS sometimes takes a second or two to mount and Reiser4 sometimes takes a second or two to unmount while all other filesystem's are instantaneous.
Whole thing available here
Not to mention mountable under Windows... for those of us that still need that. Or rather, EXT2 is mountable under Windows (with a 3rd party daemon), and thus EXT3 can be read as well.
More precisely, the PNG need to be in indexed mode (aka PNG8) for full transparency to work in IE. In The GIMP, click the "Image" menu, "Mode", "Indexed".
Some myth ("IE don't support PNG !!!") really die hard.
:wq