×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Real-World Benchmarks of Ext4

CmdrTaco posted more than 5 years ago | from the but-i-live-in-a-fake-world dept.

Data Storage 249

Ashmash writes "Phoronix has put out a fresh series of benchmarks that show the real world performance of the Ext4 file-system. They ran 19 tests on Fedora 10 with changing out their primary partition to test Ext3, Ext4, Xfs, and ReiserFS. The Linux 2.6.27 kernel was used with the latest file-system support. In the disk benchmarks like Bonnie++ Ext4 was a clear winner but with the real world tests the results were much tighter and Xfs also possessed many wins. They conclude though that Ext4 is a nice upgrade over Ext3 due to the new features and just not improved performance in a few areas, but its lifespan may be short with btrfs coming soon."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

249 comments

ext2? (5, Funny)

jon3k (691256) | more than 5 years ago | (#25975671)

What, no ext2 comparison? seems like a pretty glaring omission.

Re:ext2? (5, Funny)

Neotrantor (597070) | more than 5 years ago | (#25975771)

hey, why not a fat16 bench as well?

Spoiler alert: (ReiserFS KILLED them all !!) (0, Funny)

Anonymous Coward | more than 5 years ago | (#25976719)

When you want to go with something that leaves the others dead, go with ReiserFS. It's been proven in court to be 100% effective !!

And it can retrieve data you thought lost forever, even dead bodies !!

Re:ext2? (5, Informative)

Hal_Porter (817932) | more than 5 years ago | (#25976863)

You joke but fat with big clusters is pretty efficient for media applications. It's easy to get a good cache hit rate on the FAT cache.

E.g consider a FAT32 filesystem reading from a contiguous file. You have 512 bytes sectors 32K clusters. You have a one sector buffer for FAT data in the filesystem and a cluster sized buffer to read ahead data in the application. Each read of the FAT tells you where 128 clusters are. So you read a sector of FAT and then you can read 128 data clusters (4MB) before you need to do any metadata access. That's a very low overhead. There are no inodes to be updated, no atime and no bitmap, just the FAT, data clusters and directory entries. You need to update the time in the directory entry only once when you close the file if it has been written.

A small amount of code can get read speeds that are close to the raw read speed of the device for a contiguous file because you spend a small amount of time on bookkeeping.

Of course directories aren't indexed but lots of applications don't have vast numbers of files in a directory. In any case reading ahead as far as possible and doing a linear search is probably quicker than doing a B tree access which involves moving the hard disk head around. Even fragmentation doesn't introduce much overhead, you'd just have to reload you FAT buffer from a different place in the FAT each time you cross into a new fragment. Traditionally inode based fiesystems are worse because you have multiple levels of indirection to find the data blocks. Ext4 uses extents instead but a FAT implentation could keep track of extents in Ram so reading a big contiguous file would require FAT reads only until the filesystem works out that the file is one big extent.

If you have large directories it slows down a bit but you can always cache the mapping from files to clusters.

Most people running inode based filesystems with atime updates on, the default, probably have a filesytem which is less efficient than FAT. On Windows for example NTFS is slower than FAT in the default config with atime updates on. Kind of embarassing given that NTFS is much more high tech filesystem with Btrees fo directories and extent lists in the inodes to track data blocks.

Of course NTFS has a logfile but that only protects metadata. FAT has bit in the first FAT entry to mark the volume dirty, the idea is that you set it before you write and clear it when you're done. If you mount a filesystem with the bit set you need to do a chkdsk. Chkdsking means reading all the directories and making sure that the allocations match the FAT. It's slower than a logfile based chkdsk but it will fix corrupt metadata, mostly by freeing lost clusters. You wouldn't want to boot your OS from it, but it's good for play MP3s or AVIs from. It's also incredibly widely supported - pretty much any PC OS, games console or media player will handle it. And it works for drives of up to 2TB. Really the only problem is 4GB max file size.

Re:ext2? (2, Insightful)

Hyppy (74366) | more than 5 years ago | (#25976537)

Modded funny, but ext2 still has its uses. Journalling can be a bit of a performance breaker in the right (wrong) circumstances.

butterfs (1)

IceCreamGuy (904648) | more than 5 years ago | (#25975677)

Begin discussion revolving around what you think btrfs sounds like... again
butter file system
butterface
butt file system
etc...

Re:butterfs (2, Funny)

Rinisari (521266) | more than 5 years ago | (#25975727)

u = e?

better filesystem?

I was being facetious, but I may actually be correct.

Re:butterfs (5, Informative)

IceCreamGuy (904648) | more than 5 years ago | (#25975849)

It's actually B-Tree Filesystem, and according to Wikipedia it really is pronounced "Butter FS," however I really was just referring to the last time it was mentioned on /. and there were like 200 comments all on how they thought btrfs would be pronounced.

Re:butterfs (3, Informative)

MMC Monster (602931) | more than 5 years ago | (#25976211)

I like the fact that they are naming filesystems after characters in South Park. It's old-school programing, where you don't care what the end user thinks.

Re:butterfs (1)

operagost (62405) | more than 5 years ago | (#25976283)

With current products being named "Lame" and "Gimp," sounds like old-school is the new new-school.

Re:butterfs (1)

Ragzouken (943900) | more than 5 years ago | (#25976659)

Surely it'd either be butterfuss/bitterfuss, or Bee Tee Are Eff Ess, not pronouncing btr as it's spelt but then expanding FS to file system?

Re:butterfs (1)

dpilot (134227) | more than 5 years ago | (#25976737)

Unfortunately I tend to think of it as "Beater Eff Exx". You know, like the old car you drive in the winter, so your good car never gets near the road salt. Of course for some of us, our good summer car is a beater, too.

Re:butterfs (0)

Anonymous Coward | more than 5 years ago | (#25975803)

Don't badmouth butter unless you change your nick to IceMilkGuy. :D

Re:butterfs (3, Funny)

Directrix1 (157787) | more than 5 years ago | (#25975867)

I vote for butt rape filesystem.

Re:butterfs (5, Funny)

MightyYar (622222) | more than 5 years ago | (#25976149)

My nly prblm wth btrfs s tht t dsn't sv any vwls.

Re:butterfs (0)

Anonymous Coward | more than 5 years ago | (#25977101)

Apparently it saved the letter a in any.

Re:butterfs (1)

Daimanta (1140543) | more than 5 years ago | (#25976171)

"butter file system"

I love butter file system and I run it together with a hacked up version of "toast file system (tofsys)"

Re:butterfs (1)

sohp (22984) | more than 5 years ago | (#25976257)

At last, something to put on my flying toasters! Do you btrfs will handle the requirements of Video Toaster?

Short lifespan? I don't think so. (5, Interesting)

Viol8 (599362) | more than 5 years ago | (#25975703)

Admins tend to stick with what they know and ext4 is a natural progression from ext3. btrfs however hasn't even reached version 1.0 yet - and to be honest who is going to want to use a 1.0 release anyway on something as fundamental as a filesystem? Also its development is being done by an Oracle team , albeit FOSS , which may put a few people off.

My prediction for what its worth is that ext4 will be around for a LONG time.

Re:Short lifespan? I don't think so. (5, Funny)

IceCreamGuy (904648) | more than 5 years ago | (#25975755)

My prediction for what its worth is that ext4 will be around for a LONG time.

Like... how long? Longer than it takes to fsck an 80GB ext2 filesystem? Because that's a pretty long time.

Re:Short lifespan? I don't think so. (1)

timeOday (582209) | more than 5 years ago | (#25976777)

Longer than it takes to fsck an 80GB ext2 filesystem? Because that's a pretty long time.

Oh, are we giving ext3 a pass on this? Distros typically e2fsck ext3 filesystems every so often. Boy is it horrible when you're trying to get work done and your computer decides (without asking) to take 20 minutes to boot up.

Re:Short lifespan? I don't think so. (0, Funny)

Anonymous Coward | more than 5 years ago | (#25977245)

You reboot your Linux computer?

Re:Short lifespan? I don't think so. (3, Insightful)

statusbar (314703) | more than 5 years ago | (#25975809)

I wonder if ext4 performs better with SSD's? Or if ext4 doesn't need an occasional fsck like ext3 does?

--jeffk++

Re:Short lifespan? I don't think so. (2, Informative)

LWATCDR (28044) | more than 5 years ago | (#25976021)

What I don't understand is why more people are not using JFS?
It has good performance, it is stable, and it supports very large file systems.

Seems like a good choice for many people.

Re:Short lifespan? I don't think so. (4, Interesting)

Azar (56604) | more than 5 years ago | (#25976435)

I was wondering why it was omitted from this article as well. I believe that it's because JFS just doesn't seem to have the mindshare of ext3, XFS, or even ReiserFS. After reading various filesystem comparisons, I chose it as my FS and I have been using it for over a year without a single issue. I don't have to worry about long fsck times at reboot, my CPU has less load when deleting or copying a large volume of files (virtual machines or CD/DVD isos usually), never had any file loss or corruption, and it seems to complete large file operations quicker than ext3 (what I used previously). There are some things that ext3 does better than JFS, but overall I prefer the advantages of JFS over the advantages of ext3.

I know that if I were to rebuild an older computer that had lower specs, or perhaps a set-top box like MythTV that I wanted to be more power effecient then JFS is going to be my choice for the filesystem.

Re:Short lifespan? I don't think so. (1)

machine321 (458769) | more than 5 years ago | (#25976793)

Also its development is being done by an Oracle team

Oh, so it's Unbreakable, then.

One filesystem to rule them all... (4, Insightful)

INeededALogin (771371) | more than 5 years ago | (#25975745)

and in the darkness... bind them.

Seriously... one of the nice things about Windows, OSX, Solaris is that they get a new filesystem once every 5-10 years. The safest thing to do for Linux is to be a generation behind. I would not run ext4 until btrfs came out. Why be the admin that gets screwed with early bugs and future incompatibilities...

Re:One filesystem to rule them all... (5, Funny)

fracai (796392) | more than 5 years ago | (#25975863)

See, I already thought of that, so I run no fewer than 5 generations behind.

I started at 1, but realized that soon this practice would become widespread and then I'd be back to being an early adopter. So I moved to 2 generations. But then a friend agreed with my plan and I saw that in not too very long I'd be an early adopter again with my 2 gen old system. Not this time! I skipped the 3 and 4 generation delay and went right to the 5 generation wait time. I figured it was the only way to be sure I wouldn't get hit by any bugs.

Shoot, now the secret's out. Time to roll back my filesystem again.

Re:One filesystem to rule them all... (3, Funny)

ookabooka (731013) | more than 5 years ago | (#25976079)

Shoot, now the secret's out. Time to roll back my filesystem again.

To what? Pencil and paper?

Re:One filesystem to rule them all... (4, Funny)

compro01 (777531) | more than 5 years ago | (#25976827)

Pointy stick and a large beach.

Just be aware of occasional data loss when the tide_in function gets called.

Re:One filesystem to rule them all... (4, Informative)

The MAZZTer (911996) | more than 5 years ago | (#25975865)

Windows hasn't had a new filesystem that recently! NTFS was introduced in 1993 [wikipedia.org] . Windows has been using it for the past 15 years (if you only count the NT line, the 9x/ME line never even supported it IIRC, they just used the even older FAT32).

Of course if you want to count the small extensions [wikipedia.org] added on with each windows version then your claim about Windows is correct. Still I wouldn't be surprised if Windows Vista filesystems mount inside NT 3.1. I should test this with a VM...

Re:One filesystem to rule them all... (5, Informative)

El Lobo (994537) | more than 5 years ago | (#25976001)

Sure the NTFS used by NT4 and the one Vista uses share the same name (and are *somehow* compatible: Vista understands the old NTFS and NT4 can use the new one in a limited way, but there is A LOT under the hood. The way security descriptors work, for instance is completely different in new versions. volume Shadow Copy, Hierarchical Storage Management, Junction Points, and other "extensions" are a HUGE step forward, and made the new NTFS in reality a new version, with the same old name.

Re:One filesystem to rule them all... (3, Informative)

PitaBred (632671) | more than 5 years ago | (#25976763)

Junction points have been around since at least Win2K, possibly NT4. I know I used them on 2K personally, can't speak to NT4 though. And Volume Shadow Copy requires application cooperation [microsoft.com] , so it's not really that much of an improvement over standard mirroring unless you use copy-on-write, which is still not filesystem level. You need to have the apps aware of it.

Re:One filesystem to rule them all... (1)

macraig (621737) | more than 5 years ago | (#25976999)

I'm using junctions in this Windows 2000 system right now this very moment, thanks to a third-party shell extension or two I found that makes using them practical. One of the things I use them for is to shift some of the "default" Windows file structure locations somewhere else, without having to tweak all that stuff in the Registry. Because junctions operate under the OS radar, Windows is none the wiser that C:\Documents and Settings\username\My Documents is really just a hard link to a directory in another volume entirely.

Re:One filesystem to rule them all... (4, Interesting)

TheRaven64 (641858) | more than 5 years ago | (#25976193)

NTFS is the result of the requirements team taking too long to decide what a filesystem should do. The filesystem team on the original NT project couldn't wait for them to decide, so they produced something very simple that just stored mappings from names to two kinds of data, big and small values. Big values are stored as one or more disk blocks, small values are stored in the Master File Table (MFT).

On top of this is a metadata layer, where certain types of name are interpreted in different ways. This was used to add ACLs, encryption, compression, copy-on-write semantics, and so on.

The low-level format for a Vista NTFS partition is the same as for NT3.51, but each version of NT has added a few more types of metadata and interpretations of them, meaning that writing to a disk with an older version is likely to cause data corruption.

Re:One filesystem to rule them all... (3, Insightful)

Beat The Odds (1109173) | more than 5 years ago | (#25975869)

Seriously... one of the nice things about Windows, OSX, Solaris is that they get a new filesystem once every 5-10 years. The safest thing to do for Linux is to be a generation behind. I would not run ext4 until btrfs came out. Why be the admin that gets screwed with early bugs and future incompatibilities...

I love your sense of panic.

Anyone taking the use of ext4 seriously will setup test systems where the ONLY different is the file system. And, then, beat the crap out of it and see how it performs.

It's really pretty simple to validate this type of thing.

Re:One filesystem to rule them all... (5, Insightful)

Vancorps (746090) | more than 5 years ago | (#25977121)

You think validating the integrity of a filesystem is easy??!?!?

That's insane, first of all, you won't know how it performs unless you give it real world usage complete with disk failures. There are hundreds of file systems which can store data but how they handle problems are what separates most of them. Of course there are other distinctions but the failure mode scenarios are what most interest an admin as failure is never a question of it, only a question of when. Simulating certain failure modes is exceedingly difficult to do.

short lifespan? The big distros will decide. (3, Insightful)

Ritz_Just_Ritz (883997) | more than 5 years ago | (#25975773)

It really depends on what the larger distros choose to stick with as their default. To be honest, I'd still be using ext2 if Redhat hadn't made ext3 the default. While I'm sure that some applications depend on wringing that last few % of performance out of the spindles, it just doesn't matter THAT much for most applications.

Re:short lifespan? The big distros will decide. (5, Insightful)

INeededALogin (771371) | more than 5 years ago | (#25975927)

it just doesn't matter THAT much for most applications

well... run an fsck against ext2 and ext3 and tell me it doesn't matter. For an admin, speed, reliability, recoverability... are all major concerns. On Solaris, I love ZFS because of the functionality like snapshots and exports. I also got burned by the IDE/100% CPU driver bug on Sparc hardware. Admins need to be aware of what they are running and what limitations exist. I honest don't give a damn about mp3 encoding speed, but the capabilities and maturity of a filesystem have to be considered.

Re:short lifespan? The big distros will decide. (2, Insightful)

Chris Burke (6130) | more than 5 years ago | (#25977009)

To be honest, I'd still be using ext2 if Redhat hadn't made ext3 the default.

Well thank goodness RedHat saved you from yourself, then!

It's not about performance, it's about journaling. Ext3 has it, ext2 doesn't, ergo by modern standards ext2 is crap. The only justification for using it was when the only journaling file systems for linux were unstable.

ReiserFS (5, Funny)

thomasj (36355) | more than 5 years ago | (#25975941)

ReiserFS used to be the killer FS, but now it seems like it is stuck. But I shall not be the judge of that, though there seems to be some truth buried in it somehow. And not to mention, the next release is probably more than a few years down the road.

Re:ReiserFS (0, Redundant)

D Ninja (825055) | more than 5 years ago | (#25976037)

ReiserFS used to be the killer FS, but now it seems like it is stuck.

You're just confused. ReiserFS isn't the killer...its creator was.

Re:ReiserFS (1)

santix (1234354) | more than 5 years ago | (#25976143)

ReiserFS used to be the killer FS, but now it seems like it is stuck.

You're just confused. ReiserFS isn't the killer...its creator was.

And he's not stucked... he is in jail.

Re:ReiserFS (0)

Anonymous Coward | more than 5 years ago | (#25976213)

You're just confused. ReiserFS isn't the killer...its creator was.

Says the guy who's never lost data on a reiserfs partition...

Re:ReiserFS (1)

Hal_Porter (817932) | more than 5 years ago | (#25976277)

ReiserFS used to be the killer FS, but now it seems like it is stuck. But I shall not be the judge of that, though there seems to be some truth buried in it somehow. And not to mention, the next release is probably more than a few years down the road.

BeaterFS will absolutely slaughter ResiserFS. Bury it.

Dumbest benchmarks ever (5, Insightful)

Nick Ives (317) | more than 5 years ago | (#25976027)

I see no analysis as to why the filesystems perform the way they do. Why does XFS perform so well on a 4GB sequential read and so badly on an 8GB read? Why did they include cpu / gfx bound frame/sec benchmarks? In the few application benchmarks where there was more than a tiny fraction of percent difference there's no discussion as to whether that difference is actually significant.

Not at all enlightening.

Re:Dumbest benchmarks ever (0)

Anonymous Coward | more than 5 years ago | (#25976209)

A slashdot article posting nothing but flawed information and testing methodologies? And you're suprised!?!

You must be new here.

Re:Dumbest benchmarks ever (1)

LizardKing (5245) | more than 5 years ago | (#25977003)

Why does XFS perform so well on a 4GB sequential read and so badly on an 8GB read?

Because the cronjob that indexes the authors pr0n collection kicked in between the test runs.

Stupid testing methodology (5, Informative)

afidel (530433) | more than 5 years ago | (#25976045)

WTF who measures things like MP3 compression time when testing a filesystem?!? As far as I can tell they only ran one real I/O test and that was the Intel IOMeter based fileserver test which showed EXT4 is really fast for that profile. I would have loved to have seen the DB profile run. Their other artificial tests could have been summed up by running the streaming media profile since they were just large contiguous reads and writes.

Re:Stupid testing methodology (0)

Anonymous Coward | more than 5 years ago | (#25976493)

These aren't disk benchmarks, they're filesystem benchmarks. In the real world, large filesystem usage goes hand in hand with large cpu usage, and modern filesystems tend to use more and more CPU power to do things like checksums. Stressing the CPU while testing the FS is perfectly cromulent.

Re:Stupid testing methodology (4, Insightful)

ChrisA90278 (905188) | more than 5 years ago | (#25976761)

who measures things like MP3 compression time when testing a filesystem?!?

They were measuring what matters: "System performance" It very well could have been the case that the fastest file system, measured on a simple bench mark gives the worst MP3 compression time. Let's say the reason the filesystem is fast is because it uses a huge amount of CPU time and RAM. So a RAM based encrypted file system might be very fast, until you run an application on it.

It's a reasonable test and what it showed is that in the real-world performance is about the same

don't include JFS or XFS... -nt- (0)

Anonymous Coward | more than 5 years ago | (#25976051)

-nt-

ReiserFS (0)

Anonymous Coward | more than 5 years ago | (#25976087)

I heard that for the wife-murdering metric, ReiserFS couldn't be beat.

XFS (3, Insightful)

conspirator57 (1123519) | more than 5 years ago | (#25976139)

Given that XFS, a 15+ year old file system, is still a serious contender, one would think enough blood has been squeezed from this stone. What is left to us is application tuning and hardware improvements, possibly including filesystem management hardware. It seems to me that teaching application developers how to write their programs to best utilize the filesystem is more likely to yield better performance gains for the effort expended than trying to make a general purpose filesystem good at any flavor of IO that application developers naively throw at it. Simple rules: buffer your IO yourself, perform raw accesses in multiples of the sector/stripe size size.

Re:XFS (1)

UnknowingFool (672806) | more than 5 years ago | (#25976333)

Well I think these tests play to XFS' advantages. XFS does well with larger files and when XFS was new there were not many applications for large files except maybe in Big Iron. These days larger and larger files like movies are more the norm.

Re:XFS (3, Interesting)

sohp (22984) | more than 5 years ago | (#25976385)

Blood to squeeze? How about a new stone? Solid-state drives.

SSDs. Yep, they will completely change the rules for filesystems. Decades of tricks and tweaking to deal with rotational latency and head movement have virtually zero application in SSDs. All the code for that will become worse than useless. It will have to be removed or at least turned off. Leaving it on will actually result in worse performance on SSDs.

Re:XFS (2, Interesting)

lysergic.acid (845423) | more than 5 years ago | (#25977001)

hrm, i don't know that SSD has gained enough widespread adoption for a mainstream filesystem to be optimized for solid state rather than mechanical rotational storage. however, you do raise an interesting point. perhaps a new filesystem can be designed from the ground up optimized for SSD. whoever gets into this area of development right now will have a huge lead on competitors when SSD storage solutions finally achieve price parity with spinning media.

Re:XFS (2, Insightful)

sohp (22984) | more than 5 years ago | (#25977193)

Agreed, adoption is still pretty low, but it's definitely a game-changer. Surprisingly, SSDs might show up first en masse at the low end in netbooks like the Eee. Consider the lower power requirements and instant-on possibilities.

I can't be the only one... (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#25976145)

Who reads BTRFS as butterface.

Useless. (4, Insightful)

Steve Baker (3504) | more than 5 years ago | (#25976153)

What's with the CPU/Video tests? How about some more random access pattern tests, DB/web/streaming media tests? How about showing CPU utilization in addition to I/O performance?

bad testing (1)

ianare (1132971) | more than 5 years ago | (#25976511)

This has got to be one of the worst tests I have ever seen. Their 'real world' tests were made on operations that take mostly processor power. Without getting into the completely retarded game testing, they looked at encoding, compression, and file encryption. Sorry but for me this tells practically nothing of the speed of a file system.
I would have like to see :
creating 4gb of large files
deleting 4gb of large files
copying 4gb of large files
creating 4gb of small files
deleting 4gb of small files
copying 4gb of small files
what happens if you yank the power plug during a FS operation ?
Start up times for OpenOffice, Eclipse, and GIMP

And then, sure do the tests they ran, but not just

The stopgap always triumphs... (0)

Anonymous Coward | more than 5 years ago | (#25976519)

You know, the computer world is littered with temporary solutions that are made permanent because of incremental improvements, while the "great" solutions wither on the vine. I think ext4 will be with us for a while. We're still using TCPv4 and NAT, after all.

Stupid Names (0)

Anonymous Coward | more than 5 years ago | (#25976611)

Did you ever notice... So many nix apps have completely retarded names.

Bonnie++ lol

editors? (1)

Briden (1003105) | more than 5 years ago | (#25976627)

is this sentence written properly? they conclude though that Ext4 is a nice upgrade over Ext3 due to the new features and just not improved performance in a few areas but its lifespan may be short with btrfs coming soon."

Quit Benchmarking against Reiserfs, no one cares. (0)

Anonymous Coward | more than 5 years ago | (#25976723)

Why are people still benchmarking against reiserfs? Wouldn't it make more sense to include a benchmark against another filesystem that perhaps has a future? Like JFS?

No blogbench bench? (1)

chrysalis (50680) | more than 5 years ago | (#25976759)

Ehm, still those benchmarks filesystems are optimized for. Please try blogbench in order to make filesystem really hurt like they would do for a file server.

Interesting choice of hardware (1)

pz (113803) | more than 5 years ago | (#25976843)

Their test system is a monster 8-core, dual CPU setup, with only 2 GB of RAM. (Hell, I've got 2 GB of RAM in my dinky single-core Athlon 2800+ desktop.)

RAM is cheap and CPUs are expensive. Their system is not particularly representative since it seems to be biased in the other direction. Further, when the tests include reads and writes that are guaranteed to fill up all available RAM (sequential ops of 4 and 8 GB), the design is flawed because I/O to swap may contaminate the results.

Maybe they can fill up the four open banks on their motherboard (nice of them to show us the photo) and re-run the tests with a more realistic setup, or at least more balanced on the RAM/CPU ratio. Even better, ditch the dual quad-core Xeon (how many Linux users have that?!?) and use a more common format. The ostensible purpose is real-world testing, after all.

Re:Interesting choice of hardware (0)

Anonymous Coward | more than 5 years ago | (#25977235)

The only reason they show you the photo is because they seem to emulate hardware sites like anandtech and the 15 y.o. reading it will think it's cool. The whole site is a joke with nonsense benchmarks from people who have no clue. They should concentrate on overclocking and putting disco balls in cases thinking it will attract girls.

I stopped reading the whole article after seeing that they were testing a file system by running unreal tournament... It's probably the most useless FS benchmark I've ever read.

Hmm, they seem ignorant. (0)

Anonymous Coward | more than 5 years ago | (#25976909)

This seems to be the result of real world experience specific for their particular system..

Real Life (0)

Anonymous Coward | more than 5 years ago | (#25976973)

And when is the benchmarks for real life going to be out?

Does Phoronix even know what "Real World" means? (1)

Ant P. (974313) | more than 5 years ago | (#25977179)

Here's a few pulled-from-my-ass tests for the real world, as opposed to their real-world tests for an ad-revenue-driven world.

  1. Fill the disk with data, then write random bytes to random sectors of the disk (using a repeatable PRNG). See what percentage of the filesystem is still recoverable afterwards, and how long it takes to do a fsck on it.
  2. Time this [bash.org] .
  3. Count the number of times each FS's developers have murdered someone (hey, it's no less meaningless than measuring a FPS timedemo in terms of seconds per filesystem).

Benchmarks differ from real-world! (0)

Anonymous Coward | more than 5 years ago | (#25977263)

Film at 11. If you're awake.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...