What is Digg?27 Comments
- memphis, on 10/12/2007, -0/+2 Besides that, this article is hardly worth reading, buried in a trash heap of a webpage. The graphs are almost all misleading, and it's such a specific hardware set, that they are likely meaningless in most situations. +LAME!!
- kevinski, on 10/12/2007, -0/+1I, too, would like to see how Mac/Windows file systems stack up. I don't necessarily expect them to out-perform many (if any) of the above, but it'd be nice to see, nonetheless.
- Supergeek, on 10/12/2007, -0/+0What's needed is a script that does a lot of complicated tests to replicate an ordinary person or average server day. Most of these benchmarks bear no resemblance to everyday use.
How many people create 10,000 files at a time, delete 10,000 directories, do a find for 10,000 directories, etc.? The most useful thing some of these benchmarks prove is that something that is repeated 10,000 times in a row can reveal that some filesystems could use some optimization is certain areas.
Working with large file trees, like the kernel source, is a good test. However, these benchmarks were also run on a pretty old system;
COMPUTER: Dell Optiplex GX1
CPU: Pentium III 500MHZ
RAM: 768MB
SWAP: 2200MB
CONTROLLER: Maxtor Promise ATA/133 TX2 - IN PCI SLOT #1
DRIVES USED: 1] Seagate 400GB ATA/100 8MB CACHE 7200RPM
2] Maxtor 61.4GB ATA/66 2MB CACHE 5400RPM
DRIVE TESTED: The Seagate 400GB.
This Dell system, the GX1, was being retired by Ford Motor Company back in 1999. How about testing a modern system? Something with at least a gig of RAM and a CPU made in the past 3 years.
No digg from me; the test is incomplete and worthless with regards to modern systems. - blixel, on 10/12/2007, -0/+0What's the bottom line? I mean, I see that ReiserFS has serious issues with mounting, and that Ext2/Ext3 are particullarly good at removing files ... but are them some general conclusions that can be drawn by all of these graphs? Like ... In general, for the average Desktop user with a 100 or 200GB hard-drive, ReiserFS is the way to go ... But if you have a server system with lots of small files and a massive RAID, then you definitely want to avoid ReiserFS?
- nuxx, on 10/12/2007, -0/+0WARNING!!! this article is NOT RECOMMENDED FOR LINUX NEWBIES!!
i've been a linux user for about a year and a half now...and this confused the hell out of me...not to sound overly lazy but, i just wish this guy would give people like me a bottom line... - mooninite, on 10/12/2007, -0/+0Meaningless? Using the kernel source tree as a benchmark is an excellent choice to stress the filesystems. It's got the file sizes and file count to replicate operations of a server environment. ReiserFS fans need to put it to bed. I first started linux with ext2/3, but as soon as XFS came OSS, I jumped on board and haven't looked back.
- jdong, on 10/12/2007, -0/+0crakez: Testing FSes on ramdisks would not be fair -- reiser4 uses new Namesys write head optimizations to minimize seeks. You can even hear the difference, actually -- reiser4's operations will sound much less noisy than other FSes.
- socket, on 10/12/2007, -0/+0Good read. You just need to have an IQ higher then 42 to really understand why these are actually worthy tests. I'm afraid though most of the goons that read Digg are far too dense, or really believe they're experts in things they really know little about.
- toaste, on 10/12/2007, -0/+0I would like to see a larger test from, say, THG. Including windows and mac file systems in tests would be interesting as well. NTFS (perhaps this could be tested using captiveFS) versus Reiser 3/4 and XFS versus HFS+ would be quite interesting.
Besides the limitations of the hardware set (a faster system would reduce the latencies from cpu usage) this set of tests also neglects the effects of fragmentation on the FS. A slower file system could be worth the performance hit if it doesn't fragment files. - dgrinb01, on 10/12/2007, -0/+0I have been doing real stress testing for years on file systems, as well us running extremely demanding file servers with most of the file systems (ext2/3, reiserfs, xfs, etc.). Nothing comes even close to ReiserFS. First off, this is not a multithreaded test. Second, you have to run a test on millions of files, with combined size of tens or hundreds of gigs. I’d say, this test is a simple representation of fs usage on your desktop.
- SniperX, on 10/12/2007, -0/+0Umm.. it shows JFS as a placing near top in every test, but little to no mention of it.. Odd,
- mrlynn, on 10/12/2007, -0/+0Assuming you mean Ext2, Ext3... A digg you shall have.
- flyincomfort, on 10/12/2007, -0/+0I use XFS mostly. The only thing that really bugs me about it is that moving very large files, which is instantaneous on most other FS, takes an amount of time equivalent to copying the entire file and deleting the old copy. I wonder if any of the other FS have this behaviour...
- crackez, on 10/12/2007, -0/+0I think it would be even more telling to test these filesystems on ramdisks. Take the disk and caching out of the picture entirely. Though, now that I think of that, it might not be the best test, because RAM is pretty much completely random access at the same speed no matter where you read, but a disk backed FS would have to deal with seek times as well...
I have to agree that this is purely a desktop based test. The test machine didn't even have dual processors, so you get no impression of how this would perform on a large raid array with multiple threads banging away. It would have also been nice to see how PostgreSQL or MySQL with transaction logging performed on the various FS's. - Lagged2Death, on 10/12/2007, -0/+0I don't get it. Graphs for individual tests show some filesystems being best at certain tasks while stinking at others. It's chaos. But the summary graph:
http://linuxgazette.net/122/misc/piszcz/group002/image018.png
Shows a tidy heirarchy, with ext2 wiping the floor with everything else in every case, and the author's preferred xfs coming in dead last. That can't be right. - bnolsen, on 10/12/2007, -0/+0Yup, this test is a joke with a 500MHz P3 used for testing.
- jdong, on 10/12/2007, -0/+0Pathetic benchmark, very low quality, very meaningless results.
(1) Filesystem Creation Time: Why the heck would I care?
(2) Mount time: Again, I may care a bit more about this than creation time, but it's still not an important performance measure unless you're a bootup speed freak. Also, "hours" to mount on a RAID? How ridiculous!
(3) Total Disk Space: Very misleading graph. There is less than 25GB of difference between the largest and smallest values, less than 6% of the overall hard drive. It's unclear the methodology for this.
(4) Find 10,000 files: Note that the longest a filesystem took is 0.07 seconds, which for most humans is instantaneous.
(5) Remove 10,000 files: Results don't show full picture. Remove a 100GB file, and reiser4 will dominate and extfs will be pathetic.
I'm not going to do this for every test, but you get the point. A few more notable ones:
* File splits: Umm, caching? Or is he saying his hard drive writes near 100MB/s? - jdong, on 10/12/2007, -0/+0"The only thing that really bugs me about it is that moving very large files, which is instantaneous on most other FS, takes an amount of time equivalent to copying the entire file and deleting the old copy. I wonder if any of the other FS have this behaviour..."
Very weird -- I use XFS also and moving is just as instantaneous -- just tested with small and large files. - ahmerhussain, on 10/12/2007, -0/+0@supergeek
This a pretty average set up for a Linux system. You have to remember that the system was a controlled varable in this experiment. It doesn't really matter what the system set up was as long as it was the same through the course of teh experiment. - ahmerhussain, on 10/12/2007, -0/+0@Lagged2Death
XFS did ot perform the rest of the filesystems. I personally preffer Reiser or Ext. - ahmerhussain, on 10/12/2007, -0/+0I have a 6 gb comp and i have reiezer (slackware)
I have a comp with 40 gb with ext3 (SElinux fedora) - igutekunst, on 10/12/2007, -1/+0
" 'this story was lifted from slashdot. +LAME for submitting ***** from slashdot, no Digg'
agreed "
Both Digg and Slashot poach each other's stories all the time. If the story good, who gives a damn where you got it. I hate it when people start bashing each other for stupid reasons, like misleading titles, or lifted stories. - igutekunst, on 10/12/2007, -1/+0. . .If the story *is good. . .
- tsupersonic, on 10/12/2007, -1/+0Benchmarking Linux Filesystems
- gollo, on 10/12/2007, -3/+1"this story was lifted from slashdot. +LAME for submitting ***** from slashdot, no Digg"
agreed - apache2, on 10/12/2007, -3/+0> this story was lifted from slashdot. +LAME for submitting ***** from slashdot, no Digg
^^^ *****
>"this story was lifted from slashdot. +LAME for submitting ***** from slashdot, no Digg"
>agreed
^^^ fag
jesus, grow up you ***** - oddball, on 10/12/2007, -4/+0this story was lifted from slashdot. +LAME for submitting ***** from slashdot, no Digg
The Digg Toolbar for Firefox lets you Digg, submit content, and keep track of Digg even when you're not on the Digg site. Download the official 
© Digg Inc. 2009
— Content created and posted by Digg users is 