Linux Filesystems Benchmarked 468
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."
This discussion has been archived.
No new comments can be posted.
Linux Filesystems Benchmarked
Related Links Top of the: day, week, month.
C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup
'Tis a dupe (Score:5, Informative)
Since article has been ./ed.... (Score:5, Funny)
FAT is becoming very harmful (Score:4, Funny)
Re:Since article has been ./ed.... (Score:3, Informative)
Almost Full Article Text (Score:3, Informative)
Benchmarking Filesystems
By Justin Piszcz
INTRO
I recently purchased a Western Digital 250GB/8M/7200RPM drive and wondered which journaling file system I should use. I currently use ext2 on my other, smaller hard drives. Upon reboot or unclean shutdown, e2fsck takes a while on drives only 40 and 60 gigabytes. Therefore I knew using a journaling file system would be my best bet. The question is: which is the best? In order to determine this I used common operations that
Re:Almost Full Article Text (Score:3, Insightful)
I'm surprised that XFS did so poorly here. I do know they had a bug one point in time, which may reflect such a score, however, I thought it had long been addressed. Worse, I thought I remembered reading that XFS used a btree to track file and directory names. Please correct as needed. If this is true, it would appear to be a bug rather than normal performa
-1 Offtopic (Score:5, Funny)
So did the tests come back positive or negative? Systes are nasty things, and early detection is important to increase chances of survivability.
Remember kids. Test early, and test often. You files will thank you.
Not a clear winner (Score:5, Interesting)
EXT2 has better throughput
EXT3 has better file handling capablities
Reiser has better search ablity
XFS has better delete capablities
JFS may be a better choice in regards to file manipulation Subject to debate of course...
Re:Not a clear winner (Score:5, Informative)
Jedidiah.
Re:Not a clear winner (Score:5, Informative)
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.
Re:Not a clear winner (Score:5, Insightful)
Also, it's mountable from FreeBSD. Reiser, XFS and JFS are not.
This may seem trivial until you have a dual boot system with FreeBSD and GNU/Linux and you want to transfer your /home dir or whatever.
-JemRe:Not a clear winner (Score:5, Informative)
Re:Not a clear winner (Score:4, Informative)
Reiserfs can at least be accessed [p-nand-q.com] under Windows.
My personal peeve with ReiserFS is, though, that I've had the main ReiserFS partition on my Laptop completely destroyed by a simple power failure once. Many files were in lost+found afterwards, but some had their contents destroyed. (And restoring files by looking at their contents is not fun for ~1000 files...) So I've kinda lost trust in it. ext3 may be slow, but I've never had a single problem with it. Seems very robust to me. So, reliability is more important than speed for me (whoever needs performant servers is of course entitled to a different opinion). XFS and JFS seemingly can't be accessed from Windows, so that is a Minus for some.
Datapoints contrary to yours... (Score:4, Interesting)
We (ISP) had about 5 major data loss disasters with ext3, 3 with XFS and only 1 with reiserfs.
And we use far more reiserfs than ext3 or xfs. So from a reliability standpoint for us, reiserfs is by far more reliable than ext3 or xfs.
Re:Not a clear winner (Score:3, Informative)
"Overall Ext3 was disappointingly slow surprisingly often."
I disagree, plus this test is obsolete, why did he use a 2.4 kernel?!
from: http://freshmeat.net/projects/linux/?branch_id=463 39&release_id=160407 [freshmeat.net]
"Linux 2.6.6
...ext2 and ext3 filesystem performance was significantly improved.
"
[...]
Changes:
And thats just from today's kernel release. What about all the changes between 2.4 and now?
Considering the conveniance of backward compatability, and the fact that ext3 wasn't the worst in
Re:Not a clear winner (Score:3, Insightful)
Do you want a car that goes really, really fast, or do you want a car that gets good milage and has a really big back seat? ( You can always lie about having run out of gas).
Neither car is "best" until you define its intended use, and they both make lousy hammers. I canna change the laws of physics.
Different engineers have different ideas, different goals and different ways of g
Re:Not a clear winner (Score:4, Interesting)
I have a mailserver which have about 20GB mail with Reiser. With Ext3 it would be over 30GB.
Re:Not a clear winner (Score:3, Funny)
Re:Not a clear winner (Score:5, Insightful)
And basically the results just reiterate the design imperatives of each filesystem(how unsurprising!)
- ext2 predates them all
- ext3 is a low-impact, let's reuse what we know as much as possible, kinda file system
- reiser's b-trees reflect it's "once we put the data in, how do we find it again" orientation
- XFS was at least at one point, designed for "Media" files(think renderfarms), aka LARGE files, much of the benchmarks it won were on such files, although its design was also influenced by large-scale server needs(a renderfarm is a large-scale server cluster right?)
- JFS was influenced by large-scale server needs(databases), but tampered by OS/2's needs, and other systems, resulting in a filesystem that's a bit more nimble than XFS, but less handy with huge files(normal, since databases try to use raw-io if necessary on huge files, unlike render clusters)
I think this demonstrates the implications of early design imperatives on long-term software trends. XFS and JFS were developed for other platforms and ported to linux, yet notice how they can't really change their strengths(good thing too!).
Anyone try the same benchmark on the 2.6 kernel just to contrast it? Wouldn't the new IO-system help to mitigate those weird ext2/ext3 slowdowns the article mentions, but doesn't explain?
Re:What about HFS + (Score:3, Insightful)
Slightly OT (Score:3, Interesting)
Re:Slightly OT (Score:5, Informative)
Re:Slightly OT (Score:3, Informative)
Use the mount option data=journal, see man mount for more information.
I do know that RieserFS has some "features" that are unexpected and can be agrivated by powerfailure during write.
But don't worry, Hans says it's designed that way, and your filesystem will be intact, even if
XFS is good, but cannot be shrunk. EXT3 can shrink, but I don'
Re:Slightly OT (Score:3, Interesting)
I've heard that EXT3 cannot shrink and that ReiserFS is the only one that can. While not a demo of shrinking, here's [ibm.com] part 2 of a 3-part series of articles on using ReiserFS with LVM. This segment shows off resizing a partition without even unmounting it!
Re:Slightly OT (Score:3, Informative)
Re:Slightly OT (Score:5, Informative)
No, in fact ext3 is one of the few that actually will journal data as well as metadata.
Re:Slightly OT (Score:4, Insightful)
Slashdot filesystem (Score:5, Funny)
The real question . . . (Score:5, Funny)
That is, before it melted.
Re:The real question . . . (Score:3, Funny)
Why, with CODA [cmu.edu] of course!
I'm shocked! (Score:5, Funny)
You're right, that was a total surprise.
Your graphs are unreadable (Score:5, Insightful)
Re:Your graphs are unreadable (Score:5, Insightful)
>Use gif for images such as this.
No, use PNG.
If you're going to do it, do it right. Using GIFs is half-assed.
Re:Your graphs are unreadable (Score:4, Informative)
Re:Your graphs are unreadable (Score:5, Informative)
>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
Re:Your graphs are unreadable (Score:5, Informative)
Re:name a "major browser" that won't support PNG (Score:5, Funny)
It doesn't support GIF either though.
Re:Your graphs are unreadable (Score:5, Informative)
Re:Your graphs are unreadable (Score:5, Informative)
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.
Re:Your graphs are unreadable (Score:4, Informative)
2) Who cannot see PNGs? IE supports them, Opera supports them, Netscape/libpr0n [libpr0n.com]-based browsers all support PNGs. Hell, even Links 2 when run in X or svgalib supports PNG.
PARENT NOT INFORMATIVE (Score:5, Funny)
reiserfs? (Score:5, Funny)
I mean, really. "Mad about You" was a fine TV show... but this good?
How long until we see McKellenFS [imdb.com]?
here's the link to the original (Score:4, Informative)
it's not slashdotted yet
Hrmmm (Score:4, Interesting)
Re:Hrmmm (Score:3, Informative)
There is: gnuplot [gnuplot.info], an utterly wonderful little program. I use it all the time.
Best Filesystem for Production System (Score:3, Interesting)
It works for mine! (Score:5, Interesting)
I've got three systems currently running reiser on Gentoo, from my PowerPC/SCSI/NFS/Samba file/print server to the ancient Compaq laptop with a 4GB drive. I've never had as much as a hiccup from ReiserFS.
Under what circumstances did you lose data?
Re:It works for mine! (Score:3, Informative)
I've personally had several friends tell me of their data loss with ReiserFS. No one's arguing that it's a horrible file system, only that it still experimental.
The typical data loss situation is a power loss in the middle of a write. ReiserFS might be atomic in operation, but it still can't
Re:It works for mine! (Score:4, Informative)
My understanding is that journalled means the FS can't get into an inconsistant state and so does not need fsck-ing. It does not mean your data is safe from having the power pulled halfway through a write. If you want a super-safe home area you want some sort of logging FS and these are all far slower than journalled (I think).
Purpose of Journalling (Score:5, Interesting)
If your hardware or kernel has problems you can hardly blame a filesystem that's expressly designed for high-reliability hardware for data loss.
'journalling' is not any better than none when it comes to flaky hardware or a badly compiled kernel. All it means is that you don't have to wait an hour for fsck to run. The whole point of a journalling FS is that it 'knows' what files are suspect after a major outage and it quarantines them, it's not any better at preventing them from being corrupted.
All in all, I can say that Linux an other Unices are VERY sensitive to improper halts/panics/shutdowns. I've hosed several OS X machines by not exiting gracefully, and several Linux boxes too. Your number-one priority when setting up a system is to do what it takes to keep it from crashing, ever.
When I built my desktop I carefully selected components that were 100% Linux-compatible so I wouldn't have issues like the ones you described.
Re:It works for mine! (Score:5, Funny)
"Yeah, it's a great car. Purrs like a kitten, decent milage. It generally performs very well... except for the brakes."
Re:Best Filesystem for Production System (Score:4, Interesting)
Re:Best Filesystem for Production System (Score:4, Interesting)
However, I pinned it down to a faulty drive (Quantum Fireball, hehe, which never acted up under NTFS/Win2k.. oh well). I was close to blaming reiserfs, but once I put in a quality hard drive and reinstalled, it's run like clockwork. Perfectly.
There sure haven't been too many stabilty issues with reiserfs in my experience. Try another drive as a test and see if the same happens.
Re:Best Filesystem for Production System (Score:5, Insightful)
If your data is important, either turn off the cache on your IDE drive or buy a SCSI drive, which won't lie about fsync. This is a problem for both linux and BSD.
Later model IDE drivers and drives may be able to work properly with cache enabled, but not now. There are ongoing discussions on BOTH kernel hackers lists, BSD and Linux, about what to do, and no solution in sight.
Re:Best Filesystem for Production System (Score:3, Informative)
Please read this [oracle.com]
Just to show that it depends upon the application you need to run.
Now, you will not hear me say that you should not use ReiserFS, for a desktop it is probably the best choice, but for servers, please think again.
In addition to that, my own experiences with ReiserFS are mostly positive, especially on my 233 Mhz laptop, but I have also a big system with a Promise SX6000 raid controller, where I had a partition with ReiserFS, ext3 and JFS using Red Hat 9. Everytime I did file operations u
Re:Best Filesystem for Production System (Score:3, Informative)
It looks like Oracle has gotten the same basic results as the PostgreSQL Global Development Group have. JFS and ext3 are generally the fastest under a database, while XFS and Reiser seem to be pretty slow.
The odd thing here is that most other tests show XFS and Reiser as the kings. But the kind of random access databases do seems to be better handled by JFS / ext3.
The problems with your RAID consistency, were these file system problems, or RAID level problems? If they
The tests don't show everything (Score:5, Insightful)
Re:The tests don't show everything (Score:3, Informative)
What the fsck are you talking about? When the filesystem has problems you just need to run fsck like on any unix system from the last decade and more instead of doing the windows thing of reformatting and re-install. Certainly it's a scary thing, but you don't have to throw everything away just because you get a few easily fixable filesystem errors.
Speed means absolutely nothing (Score:5, Insightful)
Re:Speed means absolutely nothing (Score:3, Informative)
Reiserfs +IBM HD's = hair loss
Re:Speed means absolutely nothing (Score:3, Interesting)
GFS has a nice, relatively asynchronous journal implementation. However, I don't know that it will perform well on small file I/Os, particularly deletes. It's als
Re:Speed means absolutely nothing (Score:3, Funny)
Famous last word.
Any chance of including NTFS? (Score:3, Interesting)
Re:Any chance of including NTFS? (Score:4, Interesting)
WinFS is designed to utilize the database feature, I'd be really curious about the results of searching for a file in NTFS/WinFS versus a linux file system. Hopefully NTFS linux support improves to the point where we can safely use it as a linux filesystem.
Data recovery is my biggest issue right now with linux. It's damn near impossible to rescue data off a failed linux disk. Even just deleting a file is tough to recover from. NTFS has a nice selection of tools (albeit non-free) to safely and reliably recover data.
ext3 slowness (Score:5, Informative)
Re:ext3 slowness (Score:3, Insightful)
Personally, I see this as a mild security benefit. If I delete something, I want it GONE. It's not as good as an idle-time thread that 11-pass nukes unallocated sectors at random, but it'll do for a start.
So why does RedHat/Fedora continue to push EXT3? (Score:5, Interesting)
Re:So why does RedHat/Fedora continue to push EXT3 (Score:3, Insightful)
Because for most uses, it's not the best option. So, if you're going to junk ext2 compatibility, why would you go to Reiser?
Re:So why does RedHat/Fedora continue to push EXT3 (Score:4, Informative)
So, what I usually do when installing a new copy of Fedora or Redhat is to drop to a console, and use fdisk + mkfs.jfs manually. Then, when I get to the right page in the installer, I can simply set it to not reformat the partition but to use it as the "/" mount point, and voila -- my computer has JFS.
Re:So why does RedHat/Fedora continue to push EXT3 (Score:4, Informative)
You're making things unnecessarily complicated. At the "boot:" prompt, just type "linux jfs". The graphical installer will then offer it as an option. Works with reiserfs, too.
Re:So why does RedHat/Fedora continue to push EXT3 (Score:3, Interesting)
Re:So why does RedHat/Fedora continue to push EXT3 (Score:5, Interesting)
Ext3 is a very close cousin to Ext2, which has been around for a very long time, and changes very slowly. Reiser has grown and changed a LOT in the last three years, including some metadata changes that effect on-disk structures. Though it has stabalized lately, Redhat is correct to be cautious. XFS and JFS, though very mature filesystems on other OSes, have only recently become tightly integrated with the Linux kernel. Though technically controlled by the linux kernel community, all three of these other filesystems are really controlled by little cabals of people within IBM/SGI/ and then Hans Reiser. While these groups try to be transparent in their development process, Ext3 is very transparent in its development and direction.
One other tremendous advantage that Ext3 inherits from Ext2 is a fast, versatile, and effective fsck program. Journals are great in the event of power failures. However, they do not protect against Windows, or a faulty fibre channel driver, or uninformed sysadmin who accidently writes over the first 1 MB of the disk. Fsck.Ext2 is one of the best around.
Re:So why does RedHat/Fedora continue to push EXT3 (Score:4, Interesting)
Sun uses UFS because it is still the best filesystem for a root filesystem.
A more interesting question is: Why do Linux zealots incessantly rag on UFS?
One word - inertia (Score:3, Insightful)
Ext3 is stable and there's a lot of useful available tools for it.
If, for the end user, the difference is marginal, why bother to make things more difficult than necessary for yourself?
Or maybe they've received unusually many bug reports for ReiserFS and thus concluded it's not stable enough for them to push it. After all, they want to be associated with (amongst other things) reliability.
Defragmenting filesystem? (Score:3, Insightful)
Re:Defragmenting filesystem? (Score:3, Interesting)
http://oss.sgi.com/projects/xfs/manpages/xfs_fsr.
Re:Defragmenting filesystem? (Score:3, Informative)
And even if someone does put their
Re:Defragmenting filesystem? (Score:3, Informative)
Why is it hard to understand that UNIX filesystems are designed to have minimal impact on performance due to their design?
These are multiuser operating systems that
Re:Defragmenting filesystem? (Score:5, Interesting)
These days you could just use a second disk. It would be faster, too.
I wonder if there's some way for a RAID to constantly, dynamically optimize itself. After all, it's striped and redundant, there must be all kinds of funky tricks you can play to reorganize data on the fly...
Mirror (be kind) (Score:5, Informative)
http://www.gutenpress.org/links/LG/102/piszcz.htm
What about SoftUpdates? (Score:5, Interesting)
Re:What about SoftUpdates? (Score:4, Interesting)
For more info on softupdates versus journalling, see Soft Updates [usenix.org] and Journaling versus Soft Updates [usenix.org].
ext3 options (Score:5, Informative)
"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.
Re:ext3 options (Score:4, Informative)
"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 /etc/fstab and reboot, no big deal."
And where do you get the idea that this is the default? According to mount(8):
What I really would have liked to see on this benchmark is ext3 on 2.6 with dir_index enabled. (Maybe this would also gain the benefit of the Orlov allocator? I haven't been paying attention to what's been backported.) ...In fact, I would have liked to see this whole thing on 2.6.
HFS+ (Score:3, Interesting)
I'm rarely surprised... (Score:5, Insightful)
Have any of you ever been surprised?
I did some too (Score:5, Informative)
* 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 [cmu.edu]
These test need to be run on more machines (Score:4, Interesting)
We need a large sample base. Different types of chipsets, CPU's, hard-drives, etc. Then we can better see the big picture or at least see how the filesystems might perform on a system similar to your own.
So I'm calling for a "filesystem benchmark" page were people can post their results from a standard set of benchmarks. Something where they can include their system specs/setup and everything.
Then maybe we'll get useful information.
They really should have benchmarked V4 not just V3 (Score:5, Interesting)
You can see benchmarks of it at www.namesys.com/benchmarks.html [namesys.com]
"worst chartmaking...ever" (Score:3, Informative)
Unrealistic testing environment. (Score:3, Interesting)
A single process running through 10,000 files isn't particularly realistic: since when does a scaled-up server sit there and hammer the filesystem with just a single process? What about contention? Caching?
And what about recovery from errors? I didn't once see what happens if something blorts over random parts of the filesystems.. how does Reiser handle this? Ext3? XFS? Are there recovery tools in case of catastrophe?
What about these file systems stuffed into RAID volumes of various stripe sizes and configurations?
Straight deletes, creates, or modifications are useless because the only time you're going to be doing something like that is when you rm -rf * or building a new environment for.. something. Daily use, however, which eats up far more time (and thus would save the most user time if improved) is something which should been better accounted-for.
More info needed for choosing wisely (Score:3, Insightful)
I'm rapidly approaching the point where I need support for file sizes greater than 2GB. Quite frankly, most of what I've found about file sizes and file systems is 2 to 4 years old... Everyone's too concerned with speed!
large file support (Score:4, Informative)
Here's some real world information on the state of large file support in 2004. Filesystem driver support is the least of your worries -- almost any linux filesystem you can think of (except for maybe umsdos) supports over 2GB files at the kernel level. The Linux LFS [www.suse.de] page, dated April 2004, contains reasonably updated information on large file support in linux.
The bigger problem is that many userspace applications cannot yet read or write to the large files. This failure arises from non-use of the LFS API combined with just plain unfortunate use of a signed 32-bit int in the wrong place. So for instance mkisofs will reject all input files larger than 2GB in size, and cdrdao will simply abort at 2GB if you try to rip a DVD larger than 2GB in size. In some extreme cases there are programs that can't even handle large files off of the disk; one example is
wget http://mirror.linux.duke.edu/pub/fedora/linux/core /test/1.92/i386/iso/FC2-test3-i386-DVD.iso
which fails spectacularly on any x86 linux system (hint: the DVD is not really 84MB in size). In general, the "core" system utilities such as dd, cp, mv, cat are fully compatible with large files whereas third party applications are much more hit-or-miss.
Even today, by far the most practical solution to large file woes is to migrate to a 64-bit system, the most affordable of which is AMD64 by a long shot. I've been using an Athlon 64 system for the past few weeks and it has handled large files perfectly in all respects so far.
different benchmarks needed (Score:3, Insightful)
jackass article (Score:5, Insightful)
Wow...I'm really surprised that I don't see anyone else around here bashing this "benchmarking" as totally ridiculous. Get it together, people! I mean, how does a group of folks that typically pride themselves on shredding the foolish articles that come by miss these beauties:
1) This guy goes out with the stated goal of evaluating real-world performance...so he starts by throwing out all real benchmarks. Of course, those tools are designed by experts to try to represent real-world performance, but who cares, right? Instead, our jackass throws together a bundle of random operations and times them. No thought is apparent in the choices of the operations, and no discussion is given as to why the choices were made.
2) The conclusions are drawn by simply adding the times of all the tests together. If you haven't figured out why this is dumb as a rock, let me explain: test #1 took 23-40 seconds, while test #2 took .02-.04 seconds. So, in his conclusion, test #1 was weighted 1000 times as heavily as test #2. I don't know about you all, but I for one don't feel that touching speed is 1000 times as important as finding speed.
3) Even if he had normalized all the times so that the mean in each test was the same and then added those, he would still be wrong...various tests ought to be weighed differently, because real-world usage doesn't do all of these things the same amount. That said, the weight given to the tests needs to be well thought out and planned, rather than arbitrarily assigned (accidentally) without paying any attention. Interestingly enough, this sort of purposeful weighing of tests is exactly the sort of thing done by the real benchmarking tools that this idiot threw away.
4) Perhaps this one isn't as important...but this guy can't make a graph to save his life. Half the bar graphs put time on X and the other half put time on Y. Graphs that obviously should be bar graphs are made into dot-line ones. The text is blurry and you can't tell the colors in the key.
Anyway, I still don't get why everybody around here seems to have missed all this...it was painfully obvious to me when I just took a cursory glance at it.
Re:Dupe (Score:5, Funny)
Re:Bad graphs (Score:5, Funny)
Hey, he's management material! Quick promote him!
Re:Results questionable (Score:4, Informative)
Re:The conclusion (Score:3, Insightful)
I must have missed the memo
And the answer is: never.
Please give me a link to a
It would be neither legal nor ethical for Slashdot to mirror/cache content for articles posted on slashdot.
So you're saying that freecache and google are illegal?
Many site relies on banner ad revenue. Caching content would deprive those sites from the revenue generated by traffic. Plus there is the whole copyright issue.
If you don't cache the i
Re:EXT3? Lots of files changing? Increase your ... (Score:3, Interesting)
My mail server's been chugging along for about 4 years now, and is terrifically reliable. So, I turned off the fsync() calls, so things like that don't really matter any more, as the kernel's disk cache can do what it was designed to do. Throughput went up by more than a factor of ten.
Some day, a fan, power supply, or UPS will die. But getting 10x the performance for 4+ years justifies losing the two minutes worth of email that wasn't flushed to disk when that day comes.
steve