Linux File System Shootout

IpSo_ writes "Finally an extensive, human readable Linux file system benchmark has been unleashed upon us. Originally posted on the Linux Kernel mailing list, using two of the most popular benchmarking tools available, it compares all the major file systems, including their different mount options. The results are surprising."

Comments

human readable ?

[gokulpod]

I am sorry..all I see are numbers floating around. Does someone have a "human readable" summary of this ?

Re:human readable ?

[Mr_Perl]

Green is good (fastest) and red is bad (slowest)

HTH

Re:human readable ?

[maharg]

JFS is looking pretty good on the IOZone benchmarks, but the Bonnie++ benchmarks look more mixed in their findings. Remember, a benchmark is only as good as it's .... ??? WTF ?

Re:human readable ?

[rasjani]

Summary would be that jfs would rule in the IOZone for topping allmost all the scores but in the Bonnie++, top scores go about 50/50 to ext2 and jfs.

Re:human readable ?

[arivanov]

The human readable result is you need to know what you want. There is no silver bullet.

It looks like xfs wipes the floor for all but temporary (loads of create/delete) file usage. Jfs looks like the best all-rounder. Reiser looks like something that can be tuned to the specific usage, but eats CPU for breakfast, lunch and dinner and EXT3 "surprise, surprise" sucks rocks. The other "surprise, surprise" is that EXT2 is still very good for many uses.

Frankly, I do not see anything new and fascinating in the results, but they are good to throw at people who keep asking me "why not EXT3" and "Why XFS or EXT2". Here is why!

Re:human readable ?

[Anonymous Coward]

You are mistaken. ext2 and ext3_ordered(the default) seems like one of the best allrounders. ext3 journaling sucks, as expected. Thats what you pay for journaling. (No, the other filesystems does not journal data)

Re:human readable ?

[Anonymous Coward]

Summary: Open filesystems move at most 15MB/s. Worst contenders manage only half of that.

Re:human readable ?

[Lappie]

Thank the programmers for Opera zooming of websites. At least now I can see in one glance which FS has the most green bars :-)

Re:human readable ?

[msh104]

i hate this, why not use graphs. the higher the line, the better. every filesystem its own collor.

Re:human readable ?

[Anonymous Coward]

It means EXT2 is the fastest overall with JFS comming in second. I'm writing this on a ReiserFS system that I thought was pretty good.

Re:human readable ?

[Tet]

EXT3 "surprise, surprise" sucks rocks.

Really? You must be looking at a different set of benchmarks to me, because as I see it, ext3 is running a close race with XFS to take second place behind JFS. Remember, ext3's journalled mode is journalling data as well, and hence it isn't fair to compare it to other filesystems directly as it's doing much more work (equally, ext2 comes out on top for a number of things because it's doing far less work). Others like reiserfs, XFS and JFS are journalling metadata only (c.f., ext3's ordered mode).

I tend to run ext3 on all of my servers, because while it's not necessarily the absolute fastest, it's fast enough, and more importantly, it's rock solid in terms of stability. I wouldn't touch reiserfs with a 10 foot bargepole for any of my machines, mostly because I don't trust it (or Hans). Now it seems even the touted performance benefits aren't really there either. I've been considering JFS for a while, and have had a test JFS filesystem running for the last few months. Maybe I'll switch, but even if I don't, ext3 is more than adequate.

Re:human readable ?

[Anonymous Coward]

I thought it was the other way around. Red being the fastest (lowest number, least amount of write time) Green the worst (highest number, takes longer to do something.)

Re:human readable ?

[blixel]

eally? You must be looking at a different set of benchmarks to me, because as I see it

So much for the "human readable" aspect of these benchmarks. Everyone seems to be walking away with a different idea of what the results are supposed to be showing.

Since there was no legend explaining what the colors meant, I couldn't figure out anything from looking at them. Is the high number good? As in did the most work? Or is the high number bad? As in took the longest amount of time to do something?

Re:human readable ?

[msh104]

not impossible, reiser4 ( www.namesys.org ) has brenchmarks that work just this way. i personaly find this confusing because my feelings tell me that red is bad, and green is good. SO WHY ARE PEOPLE FUCKING AROUND WITH ME?

Re:human readable ?

[budgenator]

The other "surprise, surprise" is that EXT2 is still very good for many uses.
especialy if the file system can be mounted read-only; you could do this in partitions like /boot, /opt, /lib, and /usr that hold programs and are not changed often.

I wonder if the kernal version makes a difference, are the xfs and jfs better on the 2.6 as compared to say the 2.4.19 that I'm running now; or how about with files that are much smaller like on the typical web server?

also partioning schemes can make a big difference in overall performance, in the old days i placed the swap partition in the center of the disk (most accessed in the center where the heads are most likely to be) the next most likely like /usr and /var beside the swap so the heads didn't have to move to far to get to them ect.

also does the disk make a difference, such as is any performance differences consistant between scsi and ide drives?

These are things that need to be looked at before make a decision as to which is best, but it definately appears that we need to do some looking now

Re:human readable ?

[msh104]

ext2 is not journalizing. journalizing makes filesystems more complex. this is a speed v/s space issue. reiserfs never was the fastest, but namesys does claim that reiser4 is "the fastest fs". i don't know if its true or not, if they have a speed v/s features than perhaps they do. filesystems today are just to diffent for "real propper" brenchmarking.

Re:human readable ?

[Anonymous Coward]

Well, when they say "human readable", they mean humans who will know what the stats mean... if you have no idea what these tables are showing you (I find that reading the headings of each column works quite well), then what use do you have for them? and further, why do you care?

Re:human readable ?

[Psiren]

Since there was no legend explaining what the colors meant, I couldn't figure out anything from looking at them. Is the high number good? As in did the most work? Or is the high number bad? As in took the longest amount of time to do something?

Depends on the column. For K/sec, higher is better, so red cell shows lowest, and green shows highest. For %CPU, lower is better, so green shows lowest and red shows highest. It's not that complicated really if you take a few minutes to look at it. What you get from the data depends on what you were looking for in the first place.

Re:human readable ?

[mindriot]

Yep, I kinda stopped trusting Reiserfs after my notebook was visited by Colonel Panic due to a USB driver bug, and afterwards the file system was gone and could only be restored by 'reiserfsck --rebuild-tree', resulting in me manually moving back files from lost+found:

# ls
12387_55467 18392_22923 ...
# ./12387_55467
./12387_55467: missing file argument
Try `./12387_55467 --help' for more information.
# ./12387_55467 --help
(lots of output... ah! seems to have been
cp once...)
# mv ./12387_55467 /bin/cp

...and so on for about a hundred files before I was able to boot my system again. The fact that reiser totally lost its tree here made me convert to ext3 just for reasons of stability. I reproduced the USB driver bug several times with ext3 on my hard disk and never had this kind of trouble again...

In short, I couldn't care less how many megs per second my notebook can write or read if the file system is unstable. For this kind of situation, I'd rather like to see a reliability benchmark.

Re:human readable ?

[arth1]

Really? You must be looking at a different set of benchmarks to me, because as I see it, ext3 is running a close race with XFS to take second place behind JFS. Remember, ext3's journalled mode is journalling data as well, and hence it isn't fair to compare it to other filesystems directly as it's doing much more work (equally, ext2 comes out on top for a number of things because it's doing far less work). Others like reiserfs, XFS and JFS are journalling metadata only (c.f., ext3's ordered mode).

Sure, ext3 got good scores, but it also was tested in three different modes. What the testers should have done to be fair is either to only test the "default" ext3, or give other file systems the same advantage.
xfs, for example, can run with an external journal (different drive or partition), but more importantly can also be set up with a guaranteed rate IO section, giving much higher and more consistent large file sequential transfer speeds.

I also fail to see what block sizes were used. A B+ tree based file system will greatly benefit from a block size big enough to contain most small files inside the inode, but for this test, there were no small files either.

Regards,
--
*Art

Re:human readable ?

[tomstdenis]

You can scale the text [which would zoom for ya in tables] with Moz and Konq.

Whoopy.

Re:human readable ?

[Anonymous Coward]

Ext2 still good? It is completely, totally and utterly unsafe.

Before Linux had journalling filesystems, most Linux installations had unsafe, corruptible filesystems. This was one of the reasons many knowledgeable people at the time chose *BSD over Linux for server use.

Now that Linux has journalling filesystems, and several to choose from for that matter, anyone running ext2 on a server should be hit over the head with a clue stick.

Oh and people should also be aware about the write caching issue on hard disks. For safe operation, it should be disabled. Usually only hot-swappable SCSI disks for server use come with it disabled by default.

Re:human readable ?

[the morgawr]

Hardware is a huge factor. Different hardware would net vary different results.

Reiser is optimized for lots of small files. This test only tested a "few" huge files; I was actually quite surprised to see that Reiser which has had almost no optimization for this did as well as it did.I'm not surprised JFS did as well as it did either. This is what it was optimized for.

That said, what do most people keep on their Linux boxes? I'm guessing mostly small files, e.g. webpages, and configurations. For them this benchmark won't tell them anything.

Also, correct me if I'm wrong, but doesn't Reiser4 have atomic transactions built in? (i.e. it not only journals data but gaurantees it is in a consistant state) If that is the case shouldn't it be compared to ext3 instead of JFS?

My advice is for people to look at what their normal usage is and pick a file system that does well with that. (Reiser for small files, JFS for huge ones, etc.)

Re:human readable ?

[TheCrazyFinn]

Never heard of Read-only filesystems?

Mount static filesystems read-only, and make them EXT2 for performance. Use a journalling FS for dynamic filesystems. Reap the benefits of both.

Re:human readable ?

[Tet]

only test the "default" ext3

The default mode is the one that performed the best on average anyway.

xfs, for example, can run with an external journal (different drive or partition), but more importantly can also be set up with a guaranteed rate IO section

Really? Since when? Last time I looked, GRIO was only on IRIX, and wasn't supported by XFS under Linux. Incidentally, ext3 can use an external journal as well.

Re:human readable ?

[greenhide]

I tend to run ext3 on all of my servers, because while it's not necessarily the absolute fastest, it's fast enough, and more importantly, it's rock solid in terms of stability.

Right on. I think it would be much more useful to have a stability test. Take a system, and try doing weird things to it, such as running a known bug that might cause a kernel panic, and seeing how the file system deals with it.

Unplug the computer, and see how many times you can do this before the filesystem gets messed up or confused.

The statistics in these benchmarks appeal to geeks because they relate directly to "performance". It translates directly to the "horsepower" and "0 to 60 in x seconds" statistics for cars (or even, for the eco-conscious, mpg). These statistics are interesting and useful to understand the overall power of the automobile, but for a truly enjoyable car owning experience, you want to find out how reliable the car is, how often it breaks down, and how much it costs to repair. Yeah, I wouldn't mind driving a Ferrari for a day, but I'd much rather own a Subaru or Corolla.

For most people, the most important feature of a filesystem should be how well it maintains its data, and how little it gets in the way (You probably want to avoid filesystems that are CPU hogs). The only statistic that seems a little off is block output K/s for ext3_journal. If I read that correctly, it can only write ~6MB/s. That might be not enough for people who are using a hard drive to store digital video as it streams in.

Re:human readable ?

[Rich0]

I think I'd shoot myself before undertaking that operation.

I think I'd just grep the files for any sign of the data files I've edited since the last backup, etc., and then just wipe the whole thing...

Re:human readable ?

[Anonymous Coward]

I was somewhat stunned at the number of people who couldn't figure out what the red and green indicated. Phil Hartman said it best as Frankenstein: FIRE BAD ! Perhaps traffic signals would help? Green means go Red means stop Yellow means go very fast. Really. If you didn't find the chart "human readable", its far more likely that you don't fit into the "human" part than it is that the chart didn't fit into the "readable" part.

Re:human readable ?

[marx]

Except that JFS is journaled, while ext2 isn't. I'm not that dependent on speed, but given that ext3 didn't really maintain compatibility as promised, perhaps JFS should be the way to go.

Re:human readable ?

[tzanger]

Been there, done that... My problem was TCQ of (default of) 8 with DeathStar drives... Completely ate several reiserfs partitions. I lost some stuff, but most of it was recoverable.

the only reason I'm using reiser is because it will do online resize (bigger) -- a big bonus with LVM. I might take a look at jfs or xfs though, I hear they kick some ass too.

Re:human readable ?

[gmuslera]

Performance is not the only factor that is important. ext2 seems to be there as a point of reference to show a non-journaling filesystem, so if jfs scores 50/50 against ext2, i would say that is the big winner.

Re:human readable ?

[Anomylous Howard]

I find that running my ext3 journal on a RAM disk really speeds things up! Works for swap too!! ;-)

--
Trolling, trolling, trolling, keep those posts a-trolling....

Re:human readable ?

[Stephan Schulz]

reiserfs never was the fastest, but namesys does claim that reiser4 is "the fastest fs". i don't know if its true or not, if they have a speed v/s features than perhaps they do.

That is one thing to keep in mind. Another thing is to look at the hardware. They used an ancient 450 MHz Pentium-2 machine. ReiserFS always used a lot of CPU, hence it may be at least partially CPU bound. There is always a trade-off between computation (say rebalancing trees or reorganizing hashes for optimal access) and I/O. Normally, I/O cost dominates nowadays, so it makes sense to compute a lot to safe just a little bit of IO. But for the combination of a slow processor and a fast disk, things may look different.

To get more reliable results, these test should be repeated on various other configurations (and, of course, with different work loads - a news server is very different from a streaming video server).

Re:human readable ?

[Anonymous Coward]

You can't make /lib a separate partition. It contains libraries that are needed by, among others, the mount command itself:

# ldd /bin/mount
libc.so.6 => /lib/i686/libc.so.6 /lib/ld-linux.so.2 => /lib/ld-linux.so.2

If you want performance, or increased battery life on your laptop, use the "noatime" option on all your filesystems.

Re:human readable ?

[Anonymous Coward]

Green is good and Red is bad. It's not that hard to understand. And based on that, it looks to me like JFS takes the prize.

Re:human readable ?

[wmeyer]

It's not that complicated really if you take a few minutes to look at it.

Perhaps, but competently prepared tables are normally accompanied by sufficient legends to allow them to communicate clearly and without confusion.

Then, too, the lack of info on the CPU (type, speed, etc.), and system info (memory resources, disk size, type, etc.) makes the whole thing less than useful.

Re:human readable ?

[msh104]

testing reiser4 on a high performing cpu indeed might make sense. their own brenchmarks show that reiser4 is the almost most intensive cpu using filesystem there is, but also that it is the fastest. 450 MHz is not much these days, my server has an AMD-XP 2200Mhz and is under superheavy hard disk usage 70% idle, so i'd gladly burn so cpu speed for extra disk performence. so i guess i'll give it a shot

Re:human readable ?

[Anonymous Coward]

Maybe you didn't read BOTH tests, Tet, because I did, and I think ext3 came in LAST PLACE in most tests. Sometimes it finished in the middle.

EXT2, xfs, and jfs win, hands down.

Re:human readable ?

[Richy_T]

If I read that correctly, it can only write ~6MB/s. That might be not enough for people who are using a hard drive to store digital video as it streams in.

Hmm, perhaps just write the stream directly to a partition. Or perhaps a filesystem could be devised which is just a thin layer over such a scheme (perhaps dividing a partition up into a small number of stripes). files could then be cp'd over to a real FS once capture was complete. You'd only be able to store a few files on the FS but how many high-speed-data-streams do you intend capturing at once anyway?

I think Tivo does something akin to this with its MFS.

Rich

Re:human readable ?

[Tet]

Maybe you didn't read BOTH tests, Tet, because I did, and I think ext3 came in LAST PLACE in most tests.

Yep, I read both tests. They both show that ext3 in the default ordered mode is a filesystem with pretty decent performance. If you're thinking about ext3 in journalled mode, than see my other post in this thread (and those of several others, too) about why that's not a valid comparison.

Re:human readable ?

[Professor Bluebird]

Putting the journal on a ramdisk defeats the purpose of having it. In an shutdown, the journal disappears, so most of the disadvantages of ext2 return (long fsck, etc.). If speed is that critical, use ext2 and save RAM.

Re:human readable ?

[Anonymous Coward]

Um, go back to the main page and click the 'hardware used' link under the results links. I might be a coward, but still more observant that you.

Re:human readable ?

[hesiod]

> SO WHY ARE PEOPLE FUCKING AROUND WITH ME?

Because you're easily fucked with... Slut.

Re:human readable ?

[Anomylous Howard]

Sigh.

At least you don't argue with the wisdom of putting swap on a ramdisk. ;-) <--- NOTICE THE WINK THIS TIME!!!!
I also found that storing file buffers on disk improves reliability.

Here's another hint:
--
Trolling, trolling, trolling, keep those posts a-trolling....

Re:human readable ?

[Assembler]

*blink* *blink*

woah

if you're being critical, why not talk about the swap partition in ram

Re:human readable ?

[Anonymous Coward]

Yeah, it was too much for them to assume that everyone reading it would have an IQ > 3.

Re:human readable ?

[Anonymous Coward]

Is a legend really necessary? A quick scan of ONE column allows you to instantly deduce the meaning of the colors. Unless of course, one is an idiot.

Fuckwits like you probably should probably just go back to mouth breathing, and stop trying to look at tables.

Re:human readable ?

[Anonymous Coward]

This is a bunch of crap. Most servers are connected to some sort of UPS. ext2 is not utterly unsafe, and perfectly acceptable in many scenarios. If you are so paranoid, mount the damn thing sync.

Re:human readable ?

[Anonymous Coward]

Hmm, what's an IQ?

Re:human readable ?

[Anonymous Coward]

But it's easier to control (- and + keypad keys) and better done in Opera (scales the pics, too). But, sadly, some streaks appear when not at 100% scaling... :-(

Re:human readable ?

[mvpll]

ext3 rocks!

I started doing my own testing (and put it on hold after spending two weeks worth of evenings on it and constantly finding more tests worth running). I didn't include jfs at the time, now I wish I did :(

My solution for speed was ext3 with an external journal on another IDE channel.

No more disk thrashing to update the journal = ext2 speed with ext3 protection :)

Re:human readable ?

[arth1]

Last time I looked, GRIO was only on IRIX, and wasn't supported by XFS under Linux.

Sorry, I'm an old IRIX hand. It appears you are correct:

Currently, realtime partitions are not supported under the Linux version of XFS, and use of a realtime partition WILL CAUSE CORRUPTION on the data partition. As such, this command is made available for curious DEVELOPERS ONLY at this point in time.

Regards,
--
*Art

Cheaters!

[borgdows]

NTFS has been removed of the benchmark results because it was the best performer in every test!

Re:Cheaters!

[davFr]

Indeed It would be very interesting to see the results of the microsoft fs supported by linux (fat32, ntfs), as well as more exotic ones (BSD, Netfs, minix, etc).

Re:Cheaters!

[turgid]

NTFS is only there for compatibility with legacy systems (i.e. Windows) and as such, performance is not really relevant, becuase you'll probably be migrating all your data over to something better and Linux-native like Reiser.

Re:Cheaters!

[Anonymous Coward]

Interesting how you say this since the benchmarks showed that Reiser was one of the worst filesystems in almost all tests.

Re:Cheaters!

[Wolfrider]

--Reiserfs (v3.x) speed is fine if you use "notail" in the mount options. AFAIK, Reiserfs is the only one that can actuall *save space* when lots of small files are involved - at the expense of speed. Mount the fs with notail, and things speed up quite a bit.

Re:Cheaters!

[turgid]

It's a trade off between speed, space, reliablility etc. I'd rather have reliability, especially on my root paritition. Like I said, who cares about NTFS or FAT performance? Most people will only need to mount it once, read off their old data and then reformat it with something else.

The facts, although interesting, are irrelevant. This is slashdot. Get back under your bridge, troll.

Re:Cheaters!

[kasperd]

Like I said, who cares about NTFS or FAT performance?

FAT performs well as long as you just do sequential access to large files. But don't access too many files at the same time, because there are only eight entries in the fat_cache. If you run over this limit or do random access FAT is going to be the worlds slowest filesystem. And that is so bad it has really caused me trouble some times.

The reality is minix is faster, cleaner, simpler, and more flexible than FAT. Just take a look on the source minix 47KB, fat 131KB. And keep in mind that minix use a a fast tree structure to locate blocks while FAT use an extremely slow linked list.

Re:Cheaters!

[laird]

Personally, I'd like to have seen the performance of BSD's synthetic filesystem. It's a very unusual and cool filesystem that I've had good experiences with, and it'd be nice to see how it stacks up in a more scientific comparison...

Re:Cheaters!

[WindBourne]

Actually upon the final release, it would be interesting to run these tests with NTFS on linux and of course NTFS on xp. Then compare all the tests.

Re:Cheaters!

[turgid]

It wouldn't be fair, since the NTFS specs are a closely guarded secret. That's why development of the NTFS driver has been slow and incomplete on Linux. What would be more interesting would be a comparison of one of the Veritas offerings across platforms.

Re:Cheaters!

[isj]

One interesting thing I found reading msdn was that NTFS keeps track of create/modify/access time just like most *nix file systems. However, the time of last access is only kept with a granularity of 1 day. So any benchmarks comparing NTFS with *nix filesystems should use the "noatime" mount option in order to be fair.

It is an interesting tweak - most users do not care about second-precision.

Re:Cheaters!

[WindBourne]

I agree. It would not be fair to totally compare NTFS on linux vs. MS. But to compare all the various filesystems on the same hardware would be. That should include MS/NTFS, Linux/NTFS, and Linux/native FSs. I also think that these need to be done(or simply published) in a country where MSs rules for no benchmarks has no legal grounds.

Re:Cheaters!

[Anonymous Coward]

maybe most users keep all potentially important files under strict version control with md5 sums, but some of us still use timestamps and file size as a first line of defense.

Re:Cheaters!

[aardvarkjoe]

maybe most users keep all potentially important files under strict version control with md5 sums, but some of us still use timestamps and file size as a first line of defense.

This is just the last access time. I can't think of a single time that I've found knowing the last time a file has been accessed to be useful.

Re:Cheaters!

[TekPolitik]

I can't think of a single time that I've found knowing the last time a file has been accessed to be useful.

It can be very useful. One application is where you have a relatively old directory tree and are wondering if it's in active use. By finding the access time and date of the most recently used file you can make a decision to prune the tree.

/.ed already?

[tqft]

Can someone with it open mirror it please - will not open. All I can get is a 685b file

Re:/.ed already?

[Anonymous Coward]

Save the file with an extension .gz, download WinRAR and open the file. You should find it contains the file 'index.html'. Extract this file and open it in your browser. This is the webpage you were expecting.

The problem is that this web server sends gzipped pages regardless of whether the browser wants them or not.

Re:/.ed already?

[vaseyandco]

Maybe the servers file system is ext3!!

Re:/.ed already?

[bdaddy_mit]

I got the same problem. Just a 685b file. Turns out it is compressed with gzip. I was using links to view the site, and it just showed the contents of this file without decompressing it. If you grab it with wget and use gzip you can see the web pages. Maybe a newer version of links handles this better.

Re:/.ed already?

[mikehoskins]

I had no trouble reading it. I don't know if I'd bother, though. The benchmark was useless. (I WOULD look at their ACL-based permissions system for PHP, though, if you're into that kind of thing.)

Sorry this post is so long, but I must say it:

All I see JFS coming out as the clear winner, in this test, time after time after time. Hmmm, something is afoul. While I've heard that JFS is speedy, I don't believe it's THAT iron clad....

Then, I saw the hardware being tested: a single-processor 450MHz Pentium II.

I'm most familiar with ReiserFS 3 and ext2. I use ext3 for my /boot/ mount point, so I never "benchmark" it as an end user, so all my comments, below, will have a bias toward ReiserFS....

Well, ReiserFS works far better on faster machines, with more memory and cpu's than it does on slower hardware. It's designed to be scalable and handle small files better than the other FS'es.

Results: ReiserFS needs a speedy machine to perform its best. It uses CPU and memory more, as opposed to more and more disk I/O. It makes heavy use of threading and caching, by *design.* It's supposed to work that way.

Other filesystems, on the other hand, are GREAT for constrained environments.

So, I would have like to have seen at least three different speed single-processor machines and three different dual-processor machines, at least. Then, add memory a couple of times and repeat. Then, compare IDE and SCSI performance. How about RAID performance or "real-world" application performance?

NONE of this was considered, so the test is 100% worthless, for now. Hey, at least the author tried to benchmark; most people won't even do that. I hope that people submit results back to the author and they get posted, as well. Until that time, do not trust these semi-low-level disk benchmarks, even for low-level operations!

This is a shame, since I want REAL benchmark answers to this age-old question. I have NEVER seen a good FS benchmark and want to see one, soon. I know, I know, you say, "Why not just do one yourself?" OK, smarty pants, how do I do a controlled test, when I, myself, don't have 20-30 different hardware settings to test? So, I'll throw down the gauntlet to somebody with deeper pockets, no bias, and a lot of technical skill. Does anybody bite?

If JFS wins most tests on the above, well, then the stats were skewed. Why should the benchmark not show a broader mixture of "winners" and "losers?" Why does JFS almost always beat everyone else, especially under load? Is it really almost always faster?

I'm not against JFS. I used it under AIX for about 6 years, and it saved my bottom quite a few times, but I've only used it in Linux maybe one time, since ReiserFS does so much more.... In fact, I repeatedly begged for a JFS for Linux for years, until Hans Reiser's team made it a reality.

(Again, this is why you may see a preference and bias toward ReiserFS. I started using it since ReiserFS was the first journaled filesystem considered to be stable in Linux. Since then, we have a choice of at least 4 of them, plus tux2 and BeOS's FS. Also, since ReiserFS has SO little file "cluster" overhead, I primarily it over other "jfs'es" for that reason -- small files compact tightly and cache well, which is EXTREMELY important on a Unix machine.)

Also, ReiserFS version 4 is supposed to be much faster than ReiserFS 3 in most tests, which was not borne out in these benchmarks. ReiserFS 4 was very CPU intensive on these tests. However, what would you expect? ReiserFS *IS* CPU intensive and was benchmarked on an anemic single-processor IDE-based machine!!! Many single-processor machines produce about 10X the performance! Oh, BTW, what speed/configuration/type of IDE hard drive did they use?

I don't think the benchmark was fair, practical, or realistic, since other benchmarks have said that under different scenarios, different file systems peform better than others. Sometimes, ext2 wins most tests, sometimes ext3, and Reiser3 and Reiser4, and JFS, and XFS, etc....

Why should we EVER trust benchmarks on a single platform???

OK, I'll give them some credit. However, caveat emptor!

Re:The only one that matters

[maharg]

Samba is not a file system, and as such is not in the benchmarks. RTFA and see http://samba.org

Huh?

[bazik]

Woah, looks like JFS performs really well!
Anyone has good/bad experience using JFS?

Hmm... I think I'll setup my test box with JFS...

Re:Huh?

[matticus]

Well, here's IBM's page about it.

From what I've seen poking around USEnet, JFS seems to have the too little, too late problem. I've never seen it pwn a benchmark like it did today though.
I'm a little confused-I have been told XFS is the best designed, highest performing file system, and I would hate to think SGI is getting into a lot of this crap with SCO for a relatively slow journaling file system...

Re:Huh?

[ATitan]

I've got a 120 gig WD disk with JFS in my fileserver at my home network work. It's fast and since it's sharing multimedia, there is a lot of moving around, deleting and copying files around and still it's very fast writing on it ( according to my experience ).

Re:Huh?

[Frodo420024]

I'm a little confused-I have been told XFS is the best designed, highest performing file system, and I would hate to think SGI is getting into a lot of this crap with SCO for a relatively slow journaling file system...

IIRC, XFS is more about guaranteed performance under various stressful conditions than about getting the absolute peak speed in calm conditions.

Re:Huh?

[Anonymous Coward]

Time to rethink things. The generally accepted opinions between the two are that JFS is faster for small files and XFS has a bit of an edge with larger files. Both perform very very well.

I don't know how JFS falls in the "too little to late" catagory, both file systems have been available for a long time on Linux, however very few Linux distributions embrase them during installs so they have gone unknown to a great deal of the non-storage geeks out there. Mandrake, much to their credit, has for a long time included these file systems as an install option for your root filesystem, which has always made me appreicate what Mandrakes doing.

I will say that even though JFS is probly the best high-performance choise for user workstations due to smaller file sizes on average, I prefer XFS because it has a much more robust toolset and you can get alittle more hands on with the filesystem thanks to the tools provided. But most users just don't care that much for low level tools so give JFS a twirl.

Re:Huh?

[Anonymous Coward]

Acutually I made a small home-test (nothing fancy - cp) of xfs/jfs/ext3 and by copying part of the kernel tree in /dev/shm ``ramdrive'' and then on a ext3/jfs/xfs partition. Conclusion: xfs almost equal to ext3 ~25seconds (it was only 128MB of kernel), while jfs, hold on now, over 1min 15seconds (and it didn't finish to copy), maybe I did something wrong but...

Re:Huh?

[ATitan]

At least my experience is that JFS is way faster than that, altough I haven't tested xfs yet ( I plan to soon ). ext3 is way slower.

Re:Huh?

[Anonymous Coward]

It's funny you should say IBM JFS is "too little, too late", as IBM was years ahead of Sun/HP/SGI/DEC/SCO etc in introducing a journal filesystem into its Unix (AIX) in the early 90s. (Veritas may have sold a third-party add-on around then for other Unixes? But it wasn't bundled in any case.)

IBM's JFS now is different technologically (support for 64-bits and various other things), but I'd sorta agree that I've never heard a decent articulation of why it is superior to other journal filesystems. If in fact it is.

--LP

Re:Huh?

[nomadlogic]

IIRC, XFS is more about guaranteed performance under various stressful conditions than about getting the absolute peak speed in calm conditions.

and also manipulating large chunks of data quickly and efficiently. Remeber SGI is a company that is built around visualization. When working with huge image data sets I've found that XFS is really the best optioin.

Re:Huh?

[molarmass192]

I've been using JFS exclusively for about a year. Performance is good but more importantly startup times from hard resets are great and I've yet to lose a JFS partition (knocks on wood). The only negative I can think of is that SCO, in it's delusional state, seems to think they own JFS.

Re:Huh?

[TheCrazyFinn]

Don't sweat it. They think they own XFS too (It's their bitch about SGI and Linux). And since they think they own Linux, they're effectively claiming EXT2/3 too.

Haven't heard anything form them about owning ReiserFS, but that's just a matter of time.

Re:Huh?

[RustyTaco]

Funny that you should mention it, but yes. I have had /a/ problem with JFS on -test5, the kernel they tested. Somehow I managed to piss it off such that I couldn't unmount it and any attempt to access it stalled. Reboot and a VERY long (think hour or two) fsck.jfs and all seems well now. I triggered the problem by extracting the Debian XFree86 source (so I could rebuild it with optimizations to try to squeze 3 more fps from Enemy Territory :)). I'm told there was a JFS bug fixed in -test6, but I havn't scoured the archives to see if it was my bug.

I've had no other problems with it. Hell, I have 2.1T of data on a jfs filesystem right now and it seems to be doing just fine. I tried XFS but the huge block device support just wasn't there (Litterally ifdef'd out) in the kernel I tried. I saw a few XFS fixes in -test7, I might try it again now, but hell, even ext3 was able to format and mount the 2.2T successfully, even if it took an hour.

- RustyTaco

Re:Huh?

[mikehoskins]

See my comments from the above "./ed already?" post for an answer to your question....

Re:Huh?

[Yaztromo]

Woah, looks like JFS performs really well!
Anyone has good/bad experience using JFS?

I'm using JFS on three partitions on my OS/2 box. It's fast, recovers exceedingly quickly, and seems to be as solid as a rock. Using IBM's LVM, its valumes can be quickly and easily expanded across new partitions. Very slick indeed.

I haven't got around to converting any of my Linux boxes over to JFS, however, so I haven't tested it there. The Linux JFS driver is based off the OS/2 driver, however, so I'd expect similar performance.

Yaz.

Didn't jfs do well

[91degrees]

Hld on.. Isn't that the one SCO is claiming to own?

Re:Didn't jfs do well

[maharg]

... not according to IBM

Re:Didn't jfs do well

[NTmatter]

SCO has never claimed to own JFS. But then again, tomorrow's an entirely new business day, and there's a whole million lines of code that SCO hasn't yet lay claim to. ...is anyone else afraid that SCO will try to use Quantum Mechanical principles to gain ownership of the entire Linux kernel? Now, I am not a quantum physicist, but if they don't show which 50% they claim to own, won't the system be in an undetermined state? Wouldn't that mean that SCO could own both halves of the kernel at the same time?

Perhaps SCO has only lay claim to one line? This would account for the manner in which the number of lines claimed has grown from 80 to a million. This can be explained through the uncertainty principle, and compound error. The one line in question has not been determined, but has a probability of being located within certain files.

Could someone with a better grasp of mathematics please aid in identifying the SCO constant of ownership uncertainty?

Re:Didn't jfs do well

[kfg]

You are incorrect. The whole "SCO thing" started with their claim that JFS is, as a UNIX derivitive work, their IP.

It is the core issue of their suit against IBM and everything that has followed out of it.

KFG

Re:Didn't jfs do well

[SpaceLifeForm]

Actually, it is SCO that is in an uncertain state, and we only have to open the box, and SCO will be dead!

Re:Didn't jfs do well

[SpaceLifeForm]

Now Score:0, Funny. Was Score:+3, Funny.

Hey moderators, I realize the quality of education has fallen in the past 30 years, but if you don't understand the joke, don't moderate it.

Re:Didn't jfs do well

[nexex]

well, with quantum mechanics, if they tried to measure how much code is theirs, wouldn't all the code cease to exsist?

Re:Didn't jfs do well

[MuParadigm]

"...if they don't show which 50% they claim to own, won't the system be in an undetermined state?"

Only until the cat dies.

Re:Didn't jfs do well

[gullevek]

yeah well, don't expect anyone to understand the "Schroedingers cat" stuff anyway ...

Throughput benchmarks only...

[pe1chl]

There is have focus on throughput in these benchmarks. Reading and writing lots of data, seeking in files and reading data, etc.

Notably missing are more day-to-day useful operations such as the creation and deletion of lots of files, parallel action on many open files,
lots of files in a directory, etc.

When I want to select a filesystem, I do not want to know how fast it can read a 3GB file sequentially. I want to know how well it performs on a fileserver, mailserver etc.

Re:Throughput benchmarks only...

[davFr]

Notably missing are more day-to-day useful operations such as the creation and deletion of lots of files, parallel action on many open files, lots of files in a directory, etc.

Exactly! Such as when i untar mozilla sources, and it nearly freeze my system! :o)

Re:Throughput benchmarks only...

[krymsin01]

If you want to backup your dvd collection, in the most effiecient means, you might.

Re:Throughput benchmarks only...

[zurab]

Have a look at Hans' benchmarks at namesys.com. Although he only compares Reiser4 to ext3, and may not be an objective party. But I'm surprised how well JFS performed anyway and that Reiser4 is unusually CPU-intensive.

Re:Throughput benchmarks only...

[sql*kitten]

When I want to select a filesystem, I do not want to know how fast it can read a 3GB file sequentially. I want to know how well it performs on a fileserver, mailserver etc.

Horses for courses, my friend. If you are running a database or doing video editing then reading large files is exactly what you do want. This is exactly what SGI's customers do, and that is why XFS is IRIX default filesystem.

Re:Throughput benchmarks only...

[Cynic 1.0]

Ideal benchmark would be to put these servers on the net, put the latest $CO press release on em and watch as they are slashdotted :-)

Re:Throughput benchmarks only...

[CaptainZapp]

If you are running a database or doing video editing then reading large files is exactly what you do want.

Why would that be. And isn't that very dependant on the spcific database and it's storage architecture? (Not all databases use OS files)

My take is that the ability to read large files is not necessarily beneficial for a heavy duty oltp system, where you have a lot of tiny transactions.

Being fast on large files might be beneficial for table scans on huge tables (again, depending on the allocation concepts), but then again I would want to avoid that like the plague in the first place.

Re:Throughput benchmarks only...

[RustyTaco]

Notably missing are more day-to-day useful operations such as the creation and deletion of lots of files

What day-to-day operation aside from Han Reiser's "benchmark" wanking involves the creation and deletion of lots of files? A marathon pron run with mozilla creating image cache files, then you deleting them before anybody catches you?

When I want to select a filesystem, I do not want to know how fast it can read a 3GB file sequentially. I want to know how well it performs on a fileserver, mailserver etc.

What do you think a fileserver does? For the most part it reads a file sequencially and send it over the wire. And with mbox mail spool files you most definately do care how long it takes to read & write large chunks of sequencial data.

- RustyTaco

Re:Throughput benchmarks only...

[Deslack]

The press release will be cached in memory, rendering it useless as a benchmark.

Re:Throughput benchmarks only...

[valdis]

"What day-to-day operation aside from Han Reiser's "benchmark" wanking involves the creation and deletion of lots of files? A marathon pron run with mozilla creating image cache files, then you deleting them before anybody catches you?"

How about 'cd /usr/src/XFree86; make clean; make'? That's gonna remove/create shitloads of files in /usr/src, and /tmp is going to get beat on as well, even if you *do* compile with 'gcc -pipe'.

Re:Throughput benchmarks only...

[Bob Uhl]

Even with tiny transactions, good throughput is useful. RDBMSes are terribly inefficient and slow, even the best, and oftentimes need to scan through an entire table or set of tables just to display or update a view (which is, after all, merely a hard query). Every DBA I know swears by lots of spindles and mega-throughput numbers. No one ever lost money betting against the efficiency of an RDBMS.

Not that they're bad--they're actually quite excellent at ACID processing.

Re:Throughput benchmarks only...

[pe1chl]

Well, if you run a mailserver with maildir storage format, you are interested in the performance of directories with 5000 small files.
You want to quickly do readdir operations, quickly open many of the files and read some data from them, etc.

When you run a fileserver and don't want to explain to your users that it is not a good idea to have 100.000 files in a single directory as a storage format for filled-in entry forms, you want that situation to be handled well by the filesystem.

When a nightly backup operation needs to read the tree that includes that directory and write it out to a directory on a different disk (and remove the copy of a few days before), it should be able to do that without spending ridiculous amounts of time or excessively wearing out the diskdrives.

Those are not hypothetical situations, those are situations that I encounter in real life.

Re:Throughput benchmarks only...

[RustyTaco]

Well no shit. Nobody is arguing any of your points. ext2/3 tend to choke, hard, with lots of files in a directory, which is why I try to do my data filesystems as xfs or jfs, or maybe reiser if I'm not worried about keeping the data.

- RustyTaco

Re:Throughput benchmarks only...

[Anonymous Coward]

What day-to-day operation aside from Han Reiser's "benchmark" wanking involves the creation and deletion of lots of files? ... And with mbox mail spool files you most definately do care how long it takes to read & write large chunks of sequencial data.

Anyone worth their salt as an admin has moved to the Maildir format, which makes the creation and deletion of lots of files very relevant, and the mbox performance irrelevant.

Perhaps you should take a peek at what's been happening in the 21st century before sticking your foot in your mouth and being so critical. Reiserfs is very well suited to today's needs.

Re:Throughput benchmarks only...

[Anonymous Coward]

My take is that the ability to read large files is not necessarily beneficial for a heavy duty oltp system, where you have a lot of tiny transactions.

The transactions may be small, but the files are typically very large. For example, our databases here are fast approaching the three-digit gigabyte range, and we have room for three terabytes. Our databases aren't even remotely the largest things around.

i am a human

[mydigitalself]

and i cannot make head or tail of that. it should read "uber linux haxx0r geek readable". could someone please explain - in lamens terms, which one i should be using to stream my avi's off to my xbox (www.xboxmediaplayer.de) using SMB shares? ;)

Re:i am a human

[Anonymous Coward]

UDP based nfs streams video beautifully on a home network. Your server file system is not the bottleneck.

Re:i am a human

[Anonymous Coward]

...which one i should be using to stream my avi's...

And a few posts before someone else is saying how big file benchmarking is useless, and it's small file create-read-delete that matters.

Artificial benchmarks can rarely answer such questions. "Such-and-such is best" only mean "such-and-such is best at the artificial load used in the benchmark".

Streaming avi's to an xbox? Does that involve network I/O? Sorry, the presented benchmarks don't explore the interaction of network cards and disks. Such a benchmark would be highly dependent on the network card and disk controller being used (existence & interaction of DMA on the different devices). Your mileage is guaranteed to vary.

Re:i am a human

[mydigitalself]

unfortunately xbmp doesn't have nfs support :(

Re:i am a human

[1u3hr]

please explain - in lamens terms,

Is that "layman's" or "lamer's"?

Re:i am a human

[ciupman]

Everything diferent from Tom's hardware benchmark graph bars is not human readable.. i have to agree with you :D .. Please someone ask Tom to benchmark those damn things .. :)

Re:i am a human

[Crayon Kid]

Must be one of those new terms as a combination of both. Nice one.

Re:i am a human

[Raffaello]

There are certain "spelling" errors that betray a lack of knowledge about the word in question.

Layman = lay man, that is, a man who is a member of the laity.

So typing "a laymen" is not a typo, but a display of ignorance about the meaning of the word. No one mistypes men for man. "msn," or "mzn,"mqn," but not "e" for "a," as they are not adjacent on a keyboard. Moreover, "men" is the plural form, so what would "a (note singular indefinite article) lay men (note plural form of noun)" be?

This was not a typo, but just someone using a word he had heard, but didn't know the meaning of. A few posts back in this article someone did the same thing with "per se", typing "pur sang" instead. These are not typos. These are people who need to consult a dictionary more often.

Re:i am a human

[1u3hr]

So typing "a laymen" is not a typo

What he actually typed was "lamen" (no "y").

These are people who need to consult a dictionary more often.

There seem to be more such around, even in newspapers and magazines. For instance, mixing up "horde" and "hoard", "cum" (Latin, not porno) and "come"; "straight-laced" for "strait-laced" (thinking of straight vs kinky, rather than tight vs loose); "Identikit" for "identical"; and on usenet and the web you can't escape lose/loose; its/it's; etc. Being a pedant (note: that's not a pederast) is tough.

Re:i am a human

[ylikone]

Easy, red boxes mean slowest, crappiest and green boxes mean fastest, best. Not too hard if you take a bit of time to look at the numbers... but yes, they should have included a legend at least and some kind of summary graph.

Short summary

[mst76]

iozone benchmark
best: jfs
worst: ext3_journal

bonnie++ benchmark
best: ext2
worst: reiser4/reiser4_extents, ext3_ordered/ext3_journal

Re:Short summary

[richteas]

Well, that "worst" summary for reiserfs/reiser4_extents at the bonnie++ benchmark needs to be moderated a bit: reiserfs4 outperforms every other file system in its "read" capabilities. It is "worst" when it comes to CPU usage, though - but a core capability such as "read" may be a little more important.

Re:Short summary

[triptolemeus]

Outperforms all the others, might be a bit over the top. If you look at the numbers, it really doesn't outperform any of the others. It is a good one, in the top ranges, but considering the fact that the outperforming fields are green and not red...

Re:Short summary

[Spy Hunter]

bonnie++ benchmark
worst: reiser4/reiser4_extents

You might think that just based on the amount of red in Reiser4's row, but if you look all the way over to the right, you'll notice something interesting: Reiser4 often completes the benchmark in significantly less time than the other filesystems. Reiser seems to be caching a lot of flak for the CPU usage (certainly it gets a lot of red boxes in this benchmark because of it). Personally, though, I've got CPU to spare. Disk seek times aren't changing drastically anytime soon, unlike CPU speeds. If I can trade some CPU cycles for less wasted disk seek time, I think that's a great trade.

Re:Short summary

[Afrosheen]

Christ, where are my mod points when I need them most, you deserve a +1 Insightful for this.

I totally agree. CPU cycles are alot less important on my box than disk seek times. Then again, I'm guessing that the people this will be most relevant for are those running servers. Mine are all running reiserfs and ext2.

Re:Short summary

[tanveer1979]

Note fellas, though Bonnnie says reiser4 series is worst, reiserfs is one of the good ones, hanging on above avg in all counts!

Me bit confused here, arent file systems which come new(like ext3 etc) supposed to be better than the older ones!?

Re:Short summary

[Anonymous Coward]

Wrong, you miserable clods.

For the statisticians and fudsters (interpreting the meaning of best not known and can vary):
- bonnie++ benchmark:
- best: ext2
- worst: resier4*/ext3*

For the average joe (interpreting the meaning best as fastest)
- bonnie++ benchmark:
- best: reiser4*
- worst: ext3_journal

Also iozone thinks that ext3/reiser4* is the worst (slowest). Go figure.

Lies, lies!

Re:Short summary

[negyvenot]

bonnie++ benchmark
best: ext2
worst: reiser4/reiser4_extents, ext3_ordered/ext3_journal

Note that the difference between the ext2 and jfs results are close to nothing, so i would say jfs is the overall winner, as ext2 and jfs don't really compare featurewise.

Re:Short summary

[Anonymous Coward]

Reiser4 is now better in some areas, mainly speed. It is not fairing well because it is still unfinished. The Reiser4 team are now focusing on two things before releasing a more final version: increased stability and reduced processer usage (which is what currently kills Reiser4 in benchmarks).

From: Comment 7167683

We allocate a "jnode" per unformatted node in the filesystem. The traversing of these jnodes consumes more CPU than performing the memcpy from user space to kernel space when doing large writes. I don't yet really understand on an intuitive level why this is so, which is a reflection on my ignorance as it is consistent with stories I have heard from other implementors of filesystems who found that eliminating per page structures was an important part of optimizing large writes. We will fix this by creating a new structure called an extent-node that will exist on a per extent basis, and this will probably cure the problem. This will greatly simplify parts of our code for reasons I won't go into, and it will also take us 6 weeks to do it. I don't think users should wait for it, and so we will ship without it.
. . .

Our dbench performance was poor, has improved due to coding changes, and we need to test and analyze again. Perhaps more fixes will be needed, we can't say yet.

* Our fsync performance is poor. We will pay attention to this next year, frankly, after we have fully implemented the transactions API. At that point we will say something like, if you care about fsync performance you should be using the transactions API and/or sponsoring us to tune for NVRAM, users will say back "but our legacy apps on hardware without NVRAM matter!", and we will grudgingly but effectively tune for this because we care about real users too.;-)

Benchmarks can be found at www.namesys.com/benchmarks.html

Re:Short summary

[JanneM]

Not always, though, and there are definite limits. If CPU usage is too high, throughput will suddenly depend critically on the overall load of the system. To take an extreme, if it sucks up every available cycle, you can no longer depend on running other tasks while one is blocking for disk IO. There is a point, depending on the applciation and overall system load, where sacrificing more CPU for higher disk performance will hurt overall execution speed. And for stuff that is both disk and CPU intensive, that limit can be rather low.

A major reason I'm interested in a high-performace file system is an application that is CPU intensive and needs high disk throughput. For that reason, ReiserFS has never been a candidate for us, as it is so CPU-hungry.

Re:Short summary

[Anonymous Coward]

You obviously have to test for your special use-case, but the argument holds: In most cases increasing CPU speed is easier than improving disk speed (especially seek times), thus, in most cases, a filesystem which sacrifices CPU cycles to offload the harddisk is a good choice.

Re:Short summary

[Anonymous Coward]

I use ext2, and the ext2resize (or variants thereof) when I copy (dd) a partition to another HDD, and resize it to fit.

Re:Short summary

[yanestra]

Note fellas, though Bonnnie says reiser4 series is worst, reiserfs is one of the good ones, hanging on above avg in all counts!

Me bit confused here, arent file systems which come new(like ext3 etc) supposed to be better than the older ones!?

Definitely no. The "newer ones" mainly add journaling, and that means, at least meta-data has to be written twice on the physical medium, once into the journal, and once to the "real" place inside the FS' block-allocation and tree structure.

E.g. reiserfs tries to speed up things a little bit by packing very small files together, which indeed speeds up reading of small files (e.g. kernel compilation benchmarks get faster), but it doesn't help with the overall performance.

Reiserfs and others have a big problem with overhead when it comes to nearly empty disks - the database concept doesn't pay off in this case.

Re:Short summary

[ajs]

Reiser seems to be caching a lot of flak

Ah, that explains the CPU overhead then.... ;-)

Re:Short summary

[Hard_Code]

The question is, I think, does CPU load for non-disk-IO related tasks tend to increase when disk IO tends to increase. Is there a correlation? I would argue against it. Typically programs fetch data, and THEN perform operations with it. IMHO, in order to derive a cpu load/disk load correlation, you would apparently have to be doing LOTS of SMALL disk IO while simultaneously using lots of CPU. I don't think many programs operate this way. Many programs access lots of disk in small pieces, and many programs are CPU-bottlenecks, but I don't think the intersection set is all that large (if you are reading tiny amounts of data, you can't possibly being doing THAT much processing on the data right?).

Furthermore, the question becomes "is the CPU usage amortized as filesystem functionality increases". I think this is EXACTLY what we are seeing. Logic is being offloaded from individual applications and bundled into the filesystem (at least with Reiser), as more applications require more sophisticated and database-like filesystems. I think this trend will increase, and we will see more "smart" filesystems being used as databases, and less "dumb-but-fast" filesystems. Sure, applications which don't specifically use the new sophisticated features of the filesystem will see the hit, but I'd wager applications that DO use the new features would actually see a net CPU usage drop, not increase. One immediate example I see is security/ACLs and how they can be embedded in Reiser.

Re:Short summary

[MarcQuadra]

I'm with you. I'd rather have my CPU hold files in the flush buffer and order them for minimal space usage and maximum read performancde than flush them out at 'low cost' right away. I've had tremendous luch with ReiserFS 3.6, and most desktop users wil have short periods of heavy disk activity (opening an app or unpacking a tarball) followed by intensive CPU activity (using the app, compiling the tarball contents). Obviously server systems will have heavy all-around disk loading, but most servers I've seen use VERY little of their CPU, even database machines (when properly tuned).

Reiser has the right idea, leveraging the overpowered CPU to boost performance and efficencey(sp?) later.

Re:Short summary

[arthurs_sidekick]

I wonder whether there's a power usage trade off, though; the more CPU you're using, the more an (e.g.) Intel mobile chip is going to be in "full speed" mode, right? So CPU usage *could* be an issue if you like to use a laptop on batteries. Can anybody more knowledgable weigh in on this?

Re:Short summary

[JanneM]

Actually, at least in our case we thread the app, with one thread handling disk IO and other threads handling other aspects (such as CPU intensive stuff), precisely to squeeze out a bit more performance and so disk accesses do not interfere with and stall other stuff. You get this as soon as you try to do something in soft realtime (such as video applications). On one hand, you want to stream video to/from a drive as quickly and efficiently as possible; on the other, you want to do some CPU-intensive operations (filtering, resizing) on the video stream at the same time.

I'm not saying that trading CPU for filesystem speed is a bad idea; it isn't. What I'm saying is that it's not a simple "more is better" function, and that the cutoff for when it no longer makes sense does depend a lot on the application you intend it for. Again, to take an extreme, you would not want to have a system where the filesystem eats so much CPU the rest of the system essentially blocks, starved for CPU time, when the disk is used.

To take an even more extreme way of doing the tradeoff: you could compress and uncompress all data on the fly. That way you would increase transfer speed (and increase it quite a bit in the case of text files and similar) as well as decrease disk usage. It is not often done, though, because the tradeoff is not worth it in general.

For us, and our app, Reiser is on the wrong side of that cutoff point (and Reiser4 is not even on the horizon yet).

Re:Short summary

[Anonymous Coward]

You might think that just based on the amount of red in Reiser4's row, but if you look all the way over to the right, you'll notice something interesting: Reiser4 often completes the benchmark in significantly less time than the other filesystems. Reiser seems to be caching a lot of flak for the CPU usage (certainly it gets a lot of red boxes in this benchmark because of it). Personally, though, I've got CPU to spare. Disk seek times aren't changing drastically anytime soon, unlike CPU speeds. If I can trade some CPU cycles for less wasted disk seek time, I think that's a great trade.

Going ever further to the right is the column "Overall Rating". Reiser4 is pretty often red here. The overall rating is based on both the total run time and the cpu utilization. How much to penaltize for cpu utilization can be endlessly debated, since for some applications it matters while in others it doesn't. In this particular benchmark the penalty is high enough that reiser4 often loses. It is therefore a fair summary of this benchmark to say that ext3 and reiser4 are the losers. You can easily get a different result by running a different benchmark.

Re:Short summary

[BenRussoUSA]

EXT3 is exactly the same thing as EXT2, except they added a "journal" file on the filesystem and the ext3 driver makes sure to do journalling. As a matter of fact, you can mount an ext3 filesystem with an old 2.0 Linux kernel in ext2 mode. (if the filesystem was unmounted cleanly)

Re:Short summary

[Glass of Water]

It's not indicated anywhere on the pages what the numbers represent (speed? amount of data read/written?), but if it's not obvious, green indicates the winner and red indicates the loser.

Re:Short summary

[Lodragandraoidh]

To me the most important issue is response time. I replaced the standard EXT3 with ReiserFS and have seen a marked improvement when accessing files on disk. I have alot of small files on my workstation - so reiser really works for me.

Now, if I had a few large database files, then I might think of changing to something else - but I don't have that situation on my workstation, and probably never will. To echo what Spy Hunter said, I am willing to trade some CPU cycles for more efficient data retrieval - my cpu is 90% idle most times anyway (when I am not playing video games) so I have cycles to spare.

On my server, on the other hand, I am running Zope, initially using Berkely DB for the database. It is currently running redhat with EXT3 - and this will be the box where I will really need to think about performance in terms of large files as my application grows. I am also running Seti@home on this box, so CPU cycles are at a premium here.

On another note, the report itself was difficult to understand because there was no key that explained the colors or the fields. While it may be 'human readable', it is not 'human decipherable'.

Re:Short summary

[Espectr0]

If you are on a big server running cpu-intensive applications you cannot spare cpu. If that server also happens to run databases then you cant spare disk speed either.

Re:Short summary

[Anonymous Coward]

Just renice seti to 19. Then the aliens wait while the work gets done. And then CPU is only at a premium if it's incredibly important that seti do as much as possible. Anyway, reiserfs probably isn't even an option for you, since you're using big files rather than small ones. So then the cpu tradeoff will be less.

Re:Short summary

[Anonymous Coward]

Interesting. But in your extreme case of compressing and uncompressing I suspect the benchmark would _show_ that this is a bad tradeoff because I'm speculating the total time would increase.

In Reiser's case the total time _decreasing_ at the expense of just a couple-percent-of-a-cpu makes it look like a _good_ tradeoff for most all application (that aren't totally CPU-bound anyway).

Extra CPU cycles spent avoiding disk-heads-seeking, etc is almost certainly a good thing.

Re:Short summary

[Spy Hunter]

I think Reiser4 is for the most part a long way away from blocking for lack of CPU cycles. Sure, it takes more CPU than conventional filesystems, but conventional filesystems use a totally negligable amount of CPU. All things considered, the amount of CPU Reiser4 needs isn't that much, especially given Moore's law.

For desktop usage, trading CPU for disk efficiency is almost always going to be a good tradeoff. Most of the time on a desktop system when you're accessing the disk the application is blocked waiting for the results, and the user is sitting there waiting for the application. Any decrease in disk wait time is going to get those results to the user faster.

For a CPU-bound application doing lots of non-time-critical asynchronous I/O, Reiser might not be a good choice. But I think that's not a very common situation. Things like compilers don't do asynchronous I/O, they block. In a blocking situation, faster response time is better since you're just wasting CPU cycles anyway during the blocking period. If you do all your compiling in parallel you can use those CPU cycles, but most people don't.

Re:Short summary

[Spy Hunter]

Well, disk accesses take power too, so if the cpu can reduce the number of those, then overall battery usage could stay the same or even go down. It's pretty much impossible to say without testing.

Re:Short summary

[adrianbaugh]

Well said. Also, even if it is using more CPU load if it's doing so for less time the total processor time for a given write may be about the same - it's just being more efficient by doing its reads quicker, so the same total CPU time is used over a shorter period. IMO that kind of benchmark for a filesystem blows.

Re:Short summary

[antiMStroll]

Disagree. I've run a few Gentoo boxes and the latest was done Reiserf based on the install recommendations. It's a K7 1333 with 3/7 gig of RAM, and intense 7500 RPM ATA 100 disk reads - say Rox updating picture thumbnails - causes the cursor to hang and jump, CPU pegged at 100%. My P2 366 with 4200 RPM drive and 192 meg of RAM doesn't have this problem formatted XFS. Know I know why.

Next step is to download the XFS kernal sources and see how I can dump this pig of an FS.

Re:Short summary

[dvdeug]

Me bit confused here, arent file systems which come new(like ext3 etc) supposed to be better than the older ones!?

Ext3 is a journalling filesystem. The primary importance for Ext3 is that it not lose data and not require a lengthy fsck after an improper shutdown. Needless to say, if those are your goals, then you're going to be slower then a well-designed filesystem like Ext2 that assumes the system won't suddenly fail.

Re:Short summary

[Anonymous Coward]

Our mid-sized database servers are 100% disk bound.

Our big-assed database servers have obscene numbers of spindles, multiple 64bit/66Mhz PCI busses and are mostly memory bandwidth bound.

No one runs other applications on their production database servers. In fact, most IT departments have a 1 server = 1 application policy for anything even remotely important. That's why people are interested in VMware ESX Server and Microsoft Virtual Server.

Re:Short summary

[Lodragandraoidh]

Then the aliens wait while the work gets done...

Your post was mostly indecipherable - and I have difficulty understanding the logic of the above sentence...

? :(

Re:Short summary

[jovlinger]

I thought that databases really liked to speak to the raw partition, rather than lying atop a filesystem.

If that is true, then any argument about which filesystem is better for databases is moot.

these are narrow tests, not comprehensive tests

[hansreiser]

Still, they are interesting in showing areas of performance where something is a bit amiss.

It would be nice if exactly what they did was explained. You know, things like how you can get both the lowest total elapsed time and the worst overall score on one of the runs (because of CPU usage? ), what task was measured by each of the numbers printed, what the different settings on the different runs mean.....

Sigh, time to go read the source code for them.

Re:these are narrow tests, not comprehensive tests

[mst76]

Still, they are interesting in showing areas of performance where something is a bit amiss.
It would be nice if exactly what they did was explained. You know, things like how you can get both the lowest total elapsed time and the worst overall score on one of the runs (because of CPU usage? ), what task was measured by each of the numbers printed, what the different settings on the different runs mean.....

Just looking at the table of results, it seems clear that the bonnie test has a penalty for cpu utilization, while the iozone test only considers total run time.

Sigh, time to go read the source code for them.

I just hope we're not going to get benchmark-optimized filesystems.

Re:these are narrow tests, not comprehensive tests

[hansreiser]

Think of different benchmarks as being like x-ray vs. infrared photographs. Each of them gives a different insight into the subject of the photo.

In this case, I think that this 200Mhz CPU benchmark is not highly worth optimizing for, but generally more views of a design are interesting.

One of the things reiser4 needs to do is not have a structure per unformatted node for large files, and you can see the need for that if you look at our CPU consumption when writing a large file using dd. We'll probably adjust that aspect of the design sometime in the next two months, and have a structure per extent instead of per unformatted node. If I hadn't been running benchmarks, I never would have understood that misdesign decision of mine so clearly. The nice thing is that the code will get simpler as a result of the change.

Re:these are narrow tests, not comprehensive tests

[WNight]

We need real-world benchmarks then. Like AnandTech's recording of their website's DB traffic. They replay an hour of moderate traffic as fast as possible, seeing how fast easy config can handle it. It's directly relevant to their forum-heavy situation. Similar sites could probably depend on the results. And, even if not, it's a real-world test, not some synthesized benchmark that tests a task nobody'd ever do.

Re:these are narrow tests, not comprehensive tests

[mvpll]

It is all in the unlinking. From the given results, reiserfs is ~10 times faster deleting files then anything else. This would make a huge difference in the run times of the test.

The Bonnie++ website (linked from the article??) tells you what each test does.

Size on disk too?

[NicenessHimself]

Are there any similiar bakeoffs that work out efficiency with regards to different file sizes?

It would be nice if non-Linux filesystems (FATxx, NTFS etc) were also benchmarked.

Re:Size on disk too?

[drinkypoo]

FAT filesystems are garbage, there's really no real reason to benchmark them. They don't even support permissions. Would YOU use them to hold any data you care about?

NTFS can only be benchmarked on NT because linux write support for NTFS only supports NTFS4 volumes (though there IS support for dynamic disks, how funny is this) and is apparently extremely buggy in any case. So then you're benchmarking operating systems, not filesystems.

It would certainly be much, MUCH better to repeat the same tests for smaller files, larger files, and for mixtures of both small and large files.

Re:Size on disk too?

[Anonymous Coward]

>> FAT filesystems are garbage, there's really no real reason to benchmark them.

There are reasons! Read on...

>> They don't even support permissions. Would YOU use them to hold any data you care about?

Maybe not. But I'd use them for data I don't care! Suppose some data is totally duplicated and suppose it must be accessed quick. Is FAT an alternative, since the data can be lost and restored?

>> NTFS can only be benchmarked on NT because linux write support for NTFS only supports NTFS4 volumes

You can benchmark just reads and that would be useful for a read-only fs.

histogram, please!

[glenkim]

Hey, if somebody could organize this data into histograms, it'd be a lot easier to interpret the results..

Re:histogram, please!

[Malc]

Forget histograms. Ordinary bar graphs would be sufficient.

Human Readable??

[Xetrov]

I'm sory, what do you mean by "Human Readable"?

Thats one of the most difficult to read things I ever saw :)

Re:Human Readable??

[Anonymous Coward]

You need to understand the secret code:

Green = good
Red = bad

http://fsbench.netnation.com/ vs. IE ??

[plj]

The page has some weird problem. Clicking the link in IE6 triggered a question whether I want to open "fsbench.netnation(1)" directly, or save it to the disk. Same result when typing the uri manually to address bar.

No similar problems with Mozilla Firebird, though...

Re:http://fsbench.netnation.com/ vs. IE ??

[Anonymous Coward]

As the http headers indicate, the problem is that the webserver returns the page gzipped:

HTTP/1.1 200 OK
Date: Thu, 09 Oct 2003 10:10:30 GMT
Server: Apache/1.3.27 (Debian GNU/Linux) mod_perl/1.27 mod_gzip/1.3.26.1a PHP/4.3.3RC3
Content-Location: index.html.gz
Vary: negotiate
TCN: choice
Last-Modified: Thu, 09 Oct 2003 06:14:22 GMT
ETag: "2c294-2ad-3f84fcbe;3f84fcda"
Accept-Ranges: bytes
Content-Length: 685
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
Content-Encoding: x-gzip

Re:http://fsbench.netnation.com/ vs. IE ??

[Anonymous Coward]

It also doesn't allow any other type of encoding, which is a bit stupid ..

$ telnet fsbench.netnation.com 80
Trying 204.174.223.135...
Connected to fsbench.netnation.com.
Escape character is '^]'.
GET / HTTP/1.0
Host: fsbench.netnation.com
Accept-Encoding: none

HTTP/1.1 406 Not Acceptable
Date: Thu, 09 Oct 2003 10:14:49 GMT
Server: Apache/1.3.27 (Debian GNU/Linux) mod_perl/1.27 mod_gzip/1.3.26.1a PHP/4.3.3RC3
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>406 Not Acceptable</TITLE>
</HEAD><BODY>
<H1>Not Acceptable</H1>
An appropriate representation of the requested resource / could not be found on this server.<P>
Available variants:
<ul>
<li><a href="index.html.gz">index.html.gz</a> , type text/html, encoding x-gzip
</ul>
<HR>
<ADDRESS>Apache/1.3.27 Server at fsbench.netnation.com Port 80</ADDRESS>
</BODY></HTML>
Connection closed by foreign host.

Re:http://fsbench.netnation.com/ vs. IE ??

[Anonymous Coward]

It's a very simple problem. The webserver manager is an idiot. The server refuses to send non-gzipped pages. Which, by the way, means Safari and Mac IE cannot open it. Period. Idiots.

Re:http://fsbench.netnation.com/ vs. IE ??

[kfg]

They want to force Microsoft to install Linux to read it.

KFG

Re:http://fsbench.netnation.com/ vs. IE ??

[WindBourne]

They want to force Microsoft to install Linux to read it.
Of course, the real question is turn around fair play? Even when the gz library is freely available and it is already included in their kernel?

Re:http://fsbench.netnation.com/ vs. IE ??

[Anonymous Coward]

>> It's a very simple problem. The webserver manager is an idiot. The server refuses to send non-gzipped pages. Which, by the way, means Safari and Mac IE cannot open it. Period. Idiots.

_You_ are an idiot.

Use a decent browser. Not that old broken coal locomotive that is IE.

They are being slashdotted. They have the expertise to know it in advance and have taken measures to save their asses. _You_ are a dumb whiner (repeat it until you understand it).

They are giving _you_ something valuable for free; at the very minimum, speak their language!

Using IE is the mark of the stupid. You don't even have the excuse of having to use Linux, there are tons of non-breaking browsers for Windows. Use IE, but don't admit it, jerk!

As for Safari, let me ask... does Konqueror does this? No? Hmm, I guess Apple messed up some things then...

Gripping!

[NanoGator]

Juicy stories like this should be saved for Friday nights. ;)

Re:The only one that matters

[Anonymous Coward]

Which only goes to show that filesystem benchmarks are completely dumb and useless.

In a networking environment, the speed of a filesystem is not so important as the ease of interoperability between networked machines.

What I find surprising...

[Noryungi]

... is that, overall, ext2fs seems to perform better than ext3fs. I know journaling is an important advantage of ext3fs, but isn't it more important (for some applications) to have better performances?

And, as many others have already pointed out, it would be nice to have a comparison of these file systems with the *BSDs FFS...

Any comment on this would be greatly appreciated!

Re:What I find surprising...

[dacap]

Of course! That's the beauty of having choice - tune your (dedicated?) system for its application. Mix and match - make an ext2 partition for the application that needs speed and can deal with occasional data corruption. Add an XFS or JFS partition for general purpose. Add others as needed.

Database systems, which are among the slowest and most highly I/O bound of applications, take this idea to its logical extreme -- they often operate on raw partitions and handle everything themselves just to speed up I/O.

Re:What I find surprising...

[martinde]

Performance can mean lots of different things. Let's say I have a 200GB partition holding lots of (mostly) read-only data. In this case I'm not going to worry too much about write performance. Depending on the data and how I'm using it, read performance might not be a big deal either.

However, if I crash the system (accidently kick the power plug out of the UPS or something), I probably don't want to sit around for 1.5 hours while e2fsck runs. That's mainly what the journaling filesystem buys you. Perhaps the "recovery time" is the performance metric I'm most interested in.

Re:What I find surprising...

[Frodo420024]

... is that, overall, ext2fs seems to perform better than ext3fs. I know journaling is an important advantage of ext3fs, but isn't it more important (for some applications) to have better performances?

Well, in some cases (which is why we have a choice in the first place). In most cases, that's easier solved by throwing hardware at the problem - you'll gain much more speed by using fast equipment than by changing FS.

And as the amount of data increases, features such as stability, journaling or guaranteed throughput become more important than raw top speed. A bit of performance is usually well worth these in most cases.

Re:What I find surprising...

[Anonymous Coward]

Obvious. A journal is only a help in case your system crashes and you need to do an fsck. As long as the system is running allright, a journal only decreases performance.

That's true for every filesystem out there, only with ext2/ext3 you have the choice. With JFS, ReiserFS, XFS, there's no choice, and as a result, no comparison data.

Results question

[DaEMoN128]

I see that JFS won in the bonnie test, but EXT2 put up one hell of a fight and won the other roundup. I didnt think EXT2 was a journaling file system. Is it fair to thow in a Non Journaling FS in a benchmark against a bunch of Journaling ones? If it isnt journaling, then I gess Im going with JFS.

If I am wrong, please either resopond to correct me or email me.

scythefwd@yahoo.com

Re:Results question

[NickFortune]

Is it fair to thow in a Non Journaling FS in a benchmark against a bunch of Journaling ones?

Yes. Of course. The ext2 numbers provide a baseline for the comparison comparison. Any journaled FS that could match it would have to be very good indeed. This isn't explicity stated anywhere - but this was posted to the kernel list. They can reasonably be expected to know the difference between ext2 and the rest. It's all data. Data is good.

I know we're used to seeing "benchmarks" used as corporate propaganda, but let's not forget what they're supposed to be used for

Re:Results question

[Anonymous Coward]

If I am wrong, please either resopond to correct me or email me.

scythefwd@yahoo.com
Well, you'll be performing an extensive benchmark for yourself soon. Having your e-mail published will make your mail server really busy.

Re:Results question

[Wolfrider]

--Ext2 is fine for speed... Until you have to fsck. On small filesystems (~500MB or less?) it's probably not that bad, but you wouldn't want to base your whole system on it. Personally I use reiserfs with 'notail' in the mount options as a good tradeoff of speed and reliability.

--Note that resierfs v3 is the only version available right now for the stable Linux kernel; I don't even know why they bothered testing v4, because it's only in 2.6 - and alpha code, at that.

Re:Results question

[theonetruekeebler]

On the Bonnie++ benchmarks, it looked to me like ext2's biggest advantage was efficient CPU use: that's where it earned most of its green squares.

The conclusion I drew from this was that if you don't have many spare cycles cycles, e.g. by running high-crunch applications or by running with a small CPU, ext2 has its advantages.

But if primarily you using a system to serve files rather than cycles, or you expect to fsck often, by all means go with jfs.

Re:Results question

[DaEMoN128]

Thats my spam account, It doesnt matter if it dies.
I have already recieved a few viruses sent there, but I dont dl attachments, and I dont use web browsers that support vb. Yahoo is used to the spam floods, Theyll get over it.

well now there will be some testing.

[ATitan]

Looks like in my next upgrading / reinstalling cycle XFS will be the filesystem I use on my media files, the / will still be ext2 ( hey, aint broken don't fix it )

Re:well now there will be some testing.

[Anonymous Coward]

I also thought about different usage => different fs.

But I was thinking about jfs. You're right, of course, xfs is better... why compromise?

DeFacto Standard

[Bios_Hakr]

I'm not trying to be an asshole or a troll; just hear me out.

I love Reiser. I also love Gentoo and adore Debian. Myself and another guy, Joe, are the main "linux geeks" in our computer group (cugy.net). When it came time to decide what to support at our group, we had to choose RedHat.

If I'm in a message board or IRC channel, I need to know some things about the guy I'm helping. We reccomend RedHat because that is the biggest US company behind Linux (IBM and SUN notwithstanding). If I am teaching people about Linux, then it is to both our advantages to teach/learn about what we will see "in the field". Therefore, we only support RedHat.

What does this have to do with anything? Well, RedHat 9 and Severn do not allow the creation of Reiser by default. I could probably boot from a Gentoo disk and format a partition to Reiser, then install RedHat to it. But, by default, only ext* is allowed.

I love to do things that improve performance. I love testing new things on my laptop or on a offline box in our test lab. But unless RedHat offers it, it will remain in the shadows of the linux world, which is, in turn, in the shadows of the user enclave. Hell, of every important box on my network, they are either RedHat or Win2k.

More on topic, Joe got a lot of recognition when the "internet got a lot faster". Did he upgrade the firewall? Did he install another OC-3? Maybe he reconfigured services on the proxy?

Nope, he installed a hard drive, formatted it to Reiser, and moved the proxy cache to the reiser disk. I couldn't belive it. Just changing the filesystem caused an increase that was noticable across our network. At no cost!

Good work, Joe.

Re:DeFacto Standard

[pe1chl]

Well, another big player in the Linux field, SuSE, uses Reiserfs by default.

Re:DeFacto Standard

[rve]

In Suse 8.x the default appears to be Reiserfs, forcing you to make at least half a dozen mouseclicks extra during installation if you want a different root filesystem...

Re:DeFacto Standard

[evilviper]

Just because RedHat doesn't have support for ReiserFS at install-time isn't a big deal. Do the partitioning, and when you boot-up, use the reiser-tools to format the (non-system) partitions, and change your /etc/fstab to match.

Also, for something that's not important to keep across reboots (like a proxy cache) you should probably stick with Ext2, mount it async, and maybe re-create it upon reboots. That's what I do with /tmp, and just about any other high-throughput, non-important data.

Re:DeFacto Standard

[nosfucious]

Um, why would you want to put squid on a journaled file system?

Squid is a cache of (parts of) the internet. It can be rebuilt pretty easily. For example, the next time a user goes to a page. It might cost you a fraction of a second the first time, but after that you're sweet. Journalling transitory data just adds unnecessary overhead.

If it's quite a large cache with a number of binary objects, why don't you just mirror it up front?

A mail spooler or news spooler that has to keep somewhat static data I'd happily put on a journaled file system. However, Squid and things that maintain their own data integrity, (say an sql db), I'd put on Ext2.

If you're looking to restart quickly after a power failure you can always set a partition to ignore file system checks at startup, "0 0" options in /etc/fstab. /var/spool/squid (or whatever) is on its own partition right? Perhaps on it's own disk?

Re:DeFacto Standard

[ceeam]

Well - if (as another poster noted) typing "linux reiserfs" at boot prompt indeed does work, then obviously that'd be the preferred method. Still - it's really not big a problem for one to press Ctrl-Alt-F2 to escape from installation GUI to console and create/format reiserfs partition(s) manually - all the needed tools are on the path. Yes - RedHat being stubborn regarding ReiserFS amazes me. Yes - Reiser rules big time ;)

Re:DeFacto Standard

[Anonymous Coward]

Isn't Hans Reiser german? :-)

DISCLAIMER: I'm european, so I'm allowed to say these things.

Re:DeFacto Standard

[Aussie]

Um, why would you want to put squid on a journaled file system?

* Tuned to small files
* faster

seems useful for a cache too me,

Re:DeFacto Standard

[Anonymous Coward]

I suppose that would work if you re-created the filesystem from scratch at every boot. But if you run ext2 for your squid server and suddenly lose power, and don't run fsck... there's no guarantee that the filesystem is consistent. You could get parts of files missing, or pointing to other files, or munged directory entries, with the end result being scambled www pages for your users, or the proxy server crashing. Of course if you do fsck then there's no problem except that rebooting after power failure can take dozens of minutes because fsck is SLOW on a modern harddrive with dozens of gigabytes of space.

Re:DeFacto Standard

[nosfucious]

I'm aware that a journaled file system can tuned for better response to a particular situation. However, so can an unjournaled file system.

Journalling always imposes a system overhead. It might be small but it's always there. Operationally, nothing should beat a well tuned unjournaled file system. A well written journalled fs should beat a hacked together pos that doesn't do journalling.

There's always trade-offs with file systems. There isn't a perfect for everyone solution. Just some are better at some tasks than others.

Finally, I shoulda put a "YMMV" or some sort of caveat before telling someone to turn off fsck on startup. However, I think that was a minor point. Turning of filesystem checks during startup is another tradeoff (albeit a "hope and pray" one)

Re:DeFacto Standard

[nosfucious]

In some situations (i.e. Pr0n surfing and other non-critical systems), users will bitch and moan about slow response time for days/weeks/months/years until they've worked out you no longer care.

But, they'll be a pain in the arse until it's fixed and your reputation suffers little-by-little everyday.

But, speed things up, get them to quit their bitching and one half hour outage every six moths will be forgotten about by the end of the day.

Re:DeFacto Standard

[Matey-O]

Actually USING Redhat is what made me sort around for another distro. -Two major versions in a very short period of time that were largely incompatible when using third party software -Internally inconsistent administration tools that aren't available in text-mode only linux. (Why install X11 on an IDS sensor?) That say they do someing then don't. (Wireless network configuration.) -really borked package management. Yeah, you can _add_ apt-get to Redhat, but you get some oddities case it's added on. I'm really glad you made your decision for you and the people you support. I don't have access to you and have found that I got a heck of a lot further on my own with Suse. The other thing that REALLY bugs me is: resier isn't available on BSD. So I either have to learn two different distros (linux and bsd based) for internal and external use, or use something externally that has a much worse track record (NetBSD is nice and safe in the wild/ linux is very popular and 'more hackable')

Re:DeFacto Standard

[ysachlandil]

Because reiserfs is optimized for working with lots of small files...

Re:DeFacto Standard

[warpSpeed]

Um, why would you want to put squid on a journaled file system?

For the same reason you would want to have email, or a file server, on a journaled system, recovery speed.

I have some clients with servers (that run squid) and when they take a power hit, long enough to drain thier UPS, the last thing I want to have to do is deal with a call saying "how come the server did not come back up..." Meanwhile the fsck is still running and they are hitting the power switch trying to "reboot" the problem away before the ext2 fsck can finish checking though the cache partition...

Thats just on reason.

Re:DeFacto Standard

[Quixote]

Maybe he used Reiser not for its journalling capability, but for its handling of small files (tail packing).

This article from Oct 2002 talks about Reiserfs, and claims that "... ReiserFS is about eight to fifteen times faster than Ext2 at handling files smaller than 1K. "

Re:DeFacto Standard

[Syberghost]

RedHat desktops and tiny barely-supported systems in small businesses that don't have an IT department probably should ignore the benchmarks and use ext3.

Huge companies with big IT divisions can do their own application-specific benchmarks and figure out what's optimal for them.

The folks in between can use this data, however. Also, the big folks can use it for "calibration", I.E., making sure their test scripts don't provide results that vary tremendously from these results, given similar input.

Re:DeFacto Standard

[m_ilya]

It is not about tunning and it is not about journaled file system. It is about reiserfs being designed to do better work with filesystems having a lot of small files (what squid cache actually is). It is just better then ext2 for this task.

Re:DeFacto Standard

[solidox]

i would imagine the reason why Redhat use ext* by default and avoid resier is probably because the main guy behind ext development works for redhat.

Re:DeFacto Standard

[Anonymous Coward]

Nope, he installed a hard drive, formatted it to Reiser, and moved the proxy cache to the reiser disk. I couldn't belive it. Just changing the filesystem caused an increase that was noticable across our network.

Are you sure it wasn't installing the HD that helped the speed so much? I've tended to use old, low-end machines for such jobs, and it's not uncommon for them to have HDs with hdparm speeds of 5-10 MB/s. Newer HDs will do 50 from the disk and 150 from the much-larger cache. That's potentially a 30 fold speed increase. Granted, the benchmark scores make it look like reiserfs could be a 2-3 fold increase...

Re:DeFacto Standard

[hackstraw]

Um, why would you want to put squid on a journaled file system?

If you're looking to restart quickly after a power failure you can always set a partition to ignore file system checks at startup, "0 0" options in /etc/fstab. /var/spool/squid (or whatever) is on its own partition right? Perhaps on it's own disk?

You have never waited over an hour to fsck 3 harddisks while over 100 people have no "internet".

Re:DeFacto Standard

[drinkypoo]

he installed a hard drive, formatted it to Reiser, and moved the proxy cache to the reiser disk. I couldn't belive it. Just changing the filesystem caused an increase that was noticable across our network. At no cost!

He installed a hard drive. He didn't just format to reiser. The hard drive costs money.

If the proxy cache was formerly on a disk that was also doing other things, it would have sped up no matter what filesystem he used.

You will have to give us more information if you want your claims to have any merit.

Re:DeFacto Standard

[evilviper]

you want to save the proxy cache data between reboots

As I said, MAYBE erase everything. Obviously, depending on the function, and his needs.

If you were actually referring to Ext2 mounted Async being unreliable, I can definately assure you that the performance improvements, over a long period of time, are much more than worth the chance that you MIGHT loose all that data (only a slight chance, even if the system crashes, or the power fails and it's not on a UPS).

Re:DeFacto Standard

[Anonymous Coward]

WTF are you doing using a _hard_drive_ as proxy cache in the enterprise? For a proxy to be worth a shit (speed-wise) it needs to be in RAM. 1GiB+ of RAM (for a large base of users) is the MINIMUM and it takes about a week of everyone surfing to fill up with usefull data. Look in the back issues of Cisco's Internet Protocol Journal for a good source of info or talk to folks on NANOG.

Re:DeFacto Standard

[Umrick]

On the other hand, I've also had both Reiserfs and a Ext3 come back up after a poweroutage and refuse to boot as they needed to be manually fsck'd. Journaling is no magic bullet, though it'll help in a lot of cases.

Both cases were machines with otherwise longish (3+ month) uptimes.

Re:DeFacto Standard

[Anonymous Coward]

He's American or so I've read everywhere.

But he is a good guy, nonetheless... :-P

Re:DeFacto Standard

[Anonymous Coward]

>> Um, why would you want to put squid on a journaled file system?

I was told our proxy would take an entire week to get snappy after being rebuilt... we have thousands accessing different pages...

Re:DeFacto Standard

[Anonymous Coward]

>> 1GiB+ of RAM (for a large base of users)

How large?

We have maybe some 2 thousand in concurrent access to the internet... even more at certain hours (maybe at bank closing time).

Re:The only one that matters

[hdparm]

Dumb and useless, indeed. Only not benchmarks but you.

I haven't seen more incorrect statement for quite a while.

Re:The only one that matters

[MS_is_the_best]

What the author of the post you replied, probably meant, was that if the performance of a certain filesystem with samba is in a lot of cases more important than the performance of the file system pur sang, because lots of linux fileservers must be connected with window clients.

Anyway, the same accounts for DB-servers, etc. etc.

Please think before you flame ;-)

Reliability?

[hofer]

We did a lot of testing with various file systems for a product earlier this year. After a couple of terabytes of intensive reads/writes (and a couple of days...) the JFS kernel processes randomly locked up and blocked all disk I/O operations (1.1.0 and 1.1.1 versions). JFS was indeed the fastest of the file systems we tested, but we had to drop it for being unreliable.

I wonder if anyone has some experience with the reliability of the current version?

Summary

[samj]

Use XFS unless you want to do lots of deletes (as they are slow and expensive) in which case ext2 is probably a better bet since the files are probably temporary (Squid caches for example).

Re:Summary

[samj]

And if you want to use 2.4 kernels without compiling your own then you probably want to consider the 'all rounder', JFS, as 1.1.0 (or thereabouts) has been included since 2.4.20. I have a feeling XFS modifies things which weren't to be touched until 2.6.0 so you'll need a custom kernel for it. While some vendors ship 2.4 kernels with XFS support, I only really care about debian and it only ships the patch.

Re:Summary

[CAIMLAS]

You should get the woody 2.4-xfs netinst ISO, then. that's what you want. it's available on debian.org.

Re:Summary

[42forty-two42]

I've lost two filesystems to XFS - until it gets a fsck program, I'm not using it.

Re:Summary

[molarmass192]

Ummm, that's not how I interpret it. To me they both make a stronger endorsement for JFS.

Re:Summary

[slashdot_commentator]

Sorry to hear about your filesystems, but you shouldn't fault XFS for your inability to locate what you need. (Its been available in the Slackware 9 package, and probably Slackware 8.1. as well.)

Re:Summary

[Anonymous Coward]

look like someone didn't read the documentation, try repair_xfs. It isn't quite the same thing, but if FS repair is your goal; repair_xfs is much more powerful anyway. If what your worried about is that FS check on startup XFS dose that automatically whenever mounted.

Re:Summary

[joib]

My understanding is that the poor delete performance of xfs was a problem with xfs 1.0, and it was fixed in xfs 1.1. The current version, btw, is 1.3.

Re:Summary

[lardbottom]

Yeah, but booting XFS from a single floppy is basically impossible. You also have to have a special rescue CD, as XFS has a code footprint which is very large.

Don't get me wrong, I use XFS for certain specific applications, as it has a better implementation and structure internally, IMHO.

Re:Summary

[samj]

Actually I have this already. I've been installing systems with ext3 roots (for restore purposes mainly), upgrading to the kernel-image-2.6* package(s) and creating xfs /home, etc. partitions. Thanks for the heads up nonetheless.

Re:Summary

[Anonymous Coward]

I've lost two to ReiserFS, couldn't fix 'em either. I was prompted with a message telling me to try hex editing the partition table and moving stuff around until it worked.

Fuck that noise.

How about stability ?

[Anonymous Coward]

One thing that is even more important then benchmarks is the stability of the system...

I was once a very happy user of ReiserFS until the day the system kept on crashing when trying to start Mozilla...

It turned out the ReiserFS was corrupt and a rebuild of the tree was, well, not totally ok. Some of my files are corrupt still, but at least the system is running...

Does anyone have some good ideas on what filesystem is the most stable/best to reconstruct when things go FUBAR ?

Re:How about stability ?

[harikiri]

I had a very similar problem recently too. I had to recreate all my directories on the bad reiserfs partition from /lost+found after a fsck.reseirfs --rebuild-tree

But hey, at least they were there, but I still don't know what caused it in the first place. At least my blind trust of journaling filesystems has been smacked with a reality check.

I've also recently recommended reiserfs on a software raid installation at work. Lets hope that doesn't turn around and bite me in the ass. :-P

Other's don't do journaling?

[Anonymous Coward]

Uhh, I use XFS almost excluseively, and I sure am enjoying its JOURNALING features that you claim it does not have. Oh, and if I am not mistaken the J in JFS means exactly what you are claiming it doesn't. ....jackass.

Re:Other's don't do journaling?

[Anonymous Coward]

...journaling DATA... (not just filesystem metadata, which is the norm)

Re:Other's don't do journaling?

[altamira]

There is a difference between journaling DATA and METADATA. Don't get confused by that...

Re:Other's don't do journaling?

[Principal Skinner]

The J stands for Jackass? Why didn't someone tell me this earlier?

Human Readable?

[VapourFloppy]

By that classification, I'm definitely some kind of monkey...

Re:Human Readable?

[Anonymous Coward]

Technically you would be some kind of "ape."

Choosing a filesystem for antiquated systems

[Anonymous Coward]

One thing which would certainly improve the performance in these tests would be to use hardware which isn't completely outdated. They tested on a Pentium II (with matching outdated board and chipset) and a 6.4 GB harddisk. And I was wondering how no filesystem managed to move more than 15 MB/s... Come on, a low-end machine may make the differences easier to measure, but do you really want to produce the image that Linux filesystems can't move data at today's speeds? At least put abbreviated specs on the results pages.

Re:Choosing a filesystem for antiquated systems

[Spazmania]

use hardware which isn't completely outdated.

Low-end machines are an excellent choice for performing benchmarks. Why? Because the various activities tend to take long enough to be measurable.

On a higher-end machine, the relative difference is still there but its generally a lot harder to measure.

Re:Choosing a filesystem for antiquated systems

[EChris]

As much of a fan of using older hardware as I am, I have to agree with the original poster here. If you're comparing the performance of different filesystems, you don't want the hardware to be the limiting factor or you don't learn anything.

Sure, if the design of the filesystem has way too much overhead, then that's going to show up more with older systems, since more hardware speed can compensate for bad design (look at Microsoft!), but if you have an old hard disk whose read/write speed caps early, then the filesystems compared won't differentiate much.

In my opinion, probably the tests are best done on a variety of systems. One of Linux's main strengths and selling points is that it is ubiquitous and can take advantage of "legacy" hardware.

Chris

Note on ext3

[moZer]

Now, before everyone goes "I knew it! ext3 sux!!!!111!!1", remember that the default mode for ext3 is ordered, and not journal. Compare the numbers for ext3_ordered and ext3_writeback with reiser/xfs/jfs, and you'll see that ext3 is very very close in most cases.

"linux reiserfs"

[bani]

type "linux reiserfs" when booting the installer, and you will have access to reiserfs during redhat install.

i've been using this method for ~2 years now.

Re:"linux reiserfs"

[Mark Wilkinson]

Although it can leave you with a system that the Red Hat installer won't upgrade. If your root partition is actually an LVM logical volume or a RAID device, and it's formatted with reiserfs, the installer won't find your existing system and won't offer the upgrade option.

Here's my $699 now.

[clusterix]

Wow, it looks like SCO has the best filesystems for Linux with JFS and XFS.

In short

[sneakybilly]

It looks like JFS is the shit. EXT3 not so good.

Journaling!

[Anonymous Coward]

Juicy stories like this should be saved for Friday nights. ;)

You mean you're reading Slashdot on Friday nights? Get with the program, man, you're missing out on new technology! Us respectable geeks spend our Friday nights ordering "Cinemax On Demand," it even lets you pause and rewind. Good times for all.

I'll put my JFS (jackable Friday shows) against your JFS (journaling file systems) any day, especially on Friday. I bet journaling file systems don't come with a Flowmaster Hit-The-Ceiling Guarantee...

--
Rate Naked People at Fuck Meter (not work-safe!)

Re:Journaling!

[Anonymous Coward]

Depends largely on what you put on it, I guess.

Where's the deviation?

[rufusdufus]

Filesystem benchmarks can be remarkably inconsistent. These tables do not display average difference between runs. Usually this means that the methodology used to do the benchmarking is lax, and thus, untrustworthy.

For example, consider that harddrives do their own error correction. Depending on the location of marginal blocks on the media, different file systems can score dramatically for no other reason than the drive's re-mapping or error correction logic is kicking in at a bad point. Alignment of data can also be a factor in performace which depending on the formatting procedure may be completely random when compared to the file system sitting on top of it.
For these reasons and a host of others, it is not reliable to do filesystem performance comparison on a single machine.
Bottom line is that there is a good chance that these data are not fair representations of the relative merits of each filesystem.

Re:Where's the deviation?

[dublin]

Filesystem benchmarks can be remarkably inconsistent. These tables do not display average difference between runs. Usually this means that the methodology used to do the benchmarking is lax, and thus, untrustworthy.

Not only that, those charts were generated on 1998-vintage hardware with nothing in the way of modern disks or controllers. As always, the only real benchmark that matters is the one that reflects your *actual* environment.

This is not just a filesystems test, folks - disk controllers (especially if RAIDED), PCI bus bandwidth and motherboard chipset, file sizes and I/O mix, and a zillion other things all greatly affect these kinds of benchmark results. If you want maningful numbers, you'll have to generate them yourself. Fortunately, he provided the scripts, so you don't have to write your own, as we did a couple of years ago. (Get to know the benchmarks, too - both Bonnie(++) and Iozone have quirks that affect the results. And you'll porobably want to add Intel's Iometer, too if you want to be able to compare your setup with most of the publised results out there. Despite the fact that it requires Windows, it's a decent benchmark, but harder to understand and use than Bonnie.

Odd

[ThoreauHD]

Why do the benchmarks seem to be completely opposed to the other. The bonnie says reiser4 is faster, and the iozone says jfs is faster, and reiser is the slowest. This isn't making a great deal of sense to me.

Ext3

[rf0]

Well ext3 might suck but when you've only got a resuce system that can read ext2 it can really save your neck. I would be intrested to see what is best in terms of stability though..

Rus

Re:Ext3

[Cynic 1.0]

How difficult is it to carry the latest boot cd of any popular Linux distribution? You'll have support for all filesystems.

Re:Ext3

[dr.Flake]

Exactly,

I'm also very interested in the ease and ability to repair (or auto-heal) a corrupted file system after a hard crash.

Also, simple undelete would also be on my wish list. just in case.

Anyone here who's got those features ready?

Re:Ext3

[srussell]

Augh. I can't stand it any more.

I had ext3 on my wife's laptop for a while, and it failed twice. By "fail", I mean that, due to Linux crashes, the filesystem had errors that had to be recovered by hand. By "fail", I mean actual, significant data loss.

When I got my new laptop (from QliLinuxPC), they formatted the HD into one big partition (well, one for /boot and one for /), and formatted those as ext3. I didn't switch to ReiserFS, because QliLinuxPC said they'd had good luck with ext3. In the past year, I've had three seperate filesystem corruptions of / on that machine.

On my older laptop (now functioning as a print server), I have had ReiserFS for the past three years, and ReiserFS again on a desktop system for the past 5. I've only had one problem with ReiserFS, and that was three or four years ago, and I don't remember what it was -- although I remember it being a real pain to recover, and I think it involved LVM.

Considering I've tried it on two systems with entirely different hardware components, I'm faulting ext3. My conclusion is that ext3 sucks, but my opinion is based on the fact that, for a journelled filesystem, ext3 seems to be terrible at surviving sudden power failures, and has given me as many, if not more, filesystem failures than ext2 ever did.

Re:Ext3

[Anime_Fan]

While I have experienced most of what you say, I've also had my share of Reiserfs corrupting filesystem. Granted, it was not root partitions, but I had two separate IBM Deathstars (120GB) that both failed within a week (during normal usage, no power failure). I couldn't access certain directories, and a rebuild-tree saved some more files.

That said, I've not had ANY problems with Reiserfs on good hardware (Maxtor 160GB 8MB Cache/Western Digital 120GB 8Mb cache).

I would have used XFS if it wasn't for the fact that the kernel wouldn't mount the damn things ^^. But I'm now stuck with 2x 120GB ext3 partitions.

Re:Ext3

[Anonymous Coward]

AFAIK undelete is only supported by ext2. It won't work with ext3.

Re:Ext3

[Anonymous Coward]

Maybe you wife is too ignorant to use a computer. Who knows...

Re:Ext3

[Nucleon500]

AC is right, undelete is impossible on ext3.

It would be interesting for a filesystem to go out of it's way to track undeleted files, but automatically delete them when space is needed. It is, however, arguable as to whether the FS is the right place to put that - it could be (usually is) done as part of a GUI file manager, or it could be implemented as a LD_PRELOAD hack.

Re:Ext3

[bwhaley]

I once accidently deleted a file under my shiny new ext3 file system. Now, under and ext2 fs it is a piece of cake to recover a lost file - unmount the partition (ok, a little tougher if it's the root fs, but nonetheless) and go at it. Not so easy under ext3, however. I had to get a hard drive examination tool, dd the entire partition into a single image, and vi the (~13GB) file, /ing for the bits and pieces of my file.

Now I use snapshot style backup scheme. Works great.

Is this realistic?

[nemaispuke]

Is it me, or is there a lack of information about the machine the tests were run on such as why is almost all of the memory used up? Second, a system with a single disk and swap is in use? What was this guy trying to test anyhow? All this tests is basically a typical Linux box with a single drive. I wouldn't base any decision to go from one filesystem to another based on these tests!

Re:Is this realistic?

[rufusdufus]

There is a link to information about the machine. However, the rest of your comment still holds.

Re:Is this realistic?

[nagora]

All this tests is basically a typical Linux box with a single drive. I wouldn't base any decision to go from one filesystem to another based on these tests!

So you're saying that you don't want to see tests based on typical hardware? I can't think of anything better to test.

TWW

Re:Is this realistic?

[JanneM]

Well, on the other hand, for most Linux workstations and small servers, that is pretty much the standard setup. It means the results are a lot more relevant to most people than would a more "professional" one.

Re:Is this realistic?

[nemaispuke]

I think you are missing the point. In any test (especially one that is going to come in under scrutiny) all information about the target for the test should be published. There is no information about the OS (other than its Linux), what running software, what tweaks have been applied, etc. Based on what little information is provided, I doubt if anyone could duplicate the results. And the information should be available so that it can be tested independently. Everybody complains about benchmarks, but few actually put up any useful information other than the results. Hardly scientific.

Can't wait for Novell Storage System on Linux

[thehunger]

Personally, I'm happy to wait for yet another file system: Novell Storage System. It certainly is feature packed. Now before you all start banging on me, remember that Novell for years was the king of file system services. Just some of the features:

• Compression and fast decompression
• Hiearchical storage system integration
• Advanced access control model, with granular access control with inheritance and inheritance filters
• Copy on Write
• File system snapshot
• Journaling
• Transaction tracking
• DFS, Junctions and yes! symbolic links!
• Disk, directory and user level quotas
• Fast mount and repair times
• Name spaces for MAC, NFS, NCP
• Native CIFS, NFS, AFP and WebDAV protocol support
• Clustering support
• Software mirroring and RAID0 striping
• Fast! State of the art caching and read-ahead algorithms
• Low memory requirements
• Scalable: 64-bit, 8 terabyte sizes, pooling etc

I could go on... About the only thing it is missing is encryption. Of course it remains to be seen whether the port to Linux will be successful, and whether Novell has the sense to make it open source.

Re:Can't wait for Novell Storage System on Linux

[Anonymous Coward]

You forgot one thing. As an enterprise filesystem Novell was absolutely bulletproof long before RAID systems were in vogue. It took me awhile to even figure out why we needed one after years of running Novell as our main storage controller (flawlessly).

Novell could give *nix systems windows like (don't bash if you don't know) fine granularity over user access at the enterprise level along with true enterprise scaling. Again, if you have never worked in a cross enterprise environment, don't start bashing because you really can't appreciate some of Novells strengths until you need the features.

Re:Can't wait for Novell Storage System on Linux

[kasperd]

Copy on Write and directory quotas are stuff I'd really like to see in Linux filesystems. The combination of hardlinks and directory quotas is however very tricky, any pointers to implementations that made this work in the right way?

Re:Can't wait for Novell Storage System on Linux

[RiffRafff]

Isn't Novell the demon that spawned SCO?

Re:Can't wait for Novell Storage System on Linux

[ashitaka]

The one thing I gave up when we replaced or Novell boxes with Samba was really fine-grained ACL's that worked with the overlying authentication system.

Set access for a directory to an ad-hoc set of groups and permisisons flow or don;t according to a detailed set of masks.

Re:Can't wait for Novell Storage System on Linux

[Krondor]

You've got your facts half right. Novell is the company that spawned SCO (by licensing Unix to them), however Novell is hardly a demon. Novell bailed out the BSDs ages ago when AT&T was suing them for Unix. Novell purchased Unix from AT&T and dropped all lawsuits. Novell tried to stop SCO's push by countersuing them (with a claim that Novell not SCO owns the rights to enforce Unix IP). I would view Novell as more of a Shield to OSS then a traitor, of course you're welcome to your opinions ;)

Oh and as a second note NSS, JFS, and Reiser 4 look very promising to me. I can't wait to try them.

Come on not everybody understands this...

[SerpentMage]

Did you know that partial different equations attempt to solve a problem (like fluid dynamics), which can be potentially solved simpler by Wolfram's Programmatic Mathematics.

Are you saying WTF? Well, congratulations, not everybody wants to know that level of detail in a particular subject.

The results are a bunch of numbers that for some people are totally non-comprehensible because they do not understand that level of detail.

Some folks would rather know why a particular file system is better than another using a couple of words... It has nothing to do with being an MTV generation kid!

Re:Come on not everybody understands this...

[rushibhai]

Glad you used the word "potentially", otherwise there would have been an all out flame-war in the filesystems community regarding the best way to solve PDEs using ext3. :)

Readable?

[Daniel Quinlan]

Yeah, I know when I'm trying to summarize performance, I always include 1871 different numbers in a set of tables. The boss loves that. Readers love that.

Sorry, I looked at the benchmark results and quickly reached total eye glaze over. I think it could be presented a lot more clearly.

This is kinda weird

[insomaniac]

I used to have a gentoo install with a JFS partition for the system on my laptop. The laptop ran so slow that I reinstalled the whole thing with reiserfs, now it runs so much faster, so how could JFS come in so high on the benchmarks while my experience has been that its dog slow?

Re:This is kinda weird

[Anonymous Coward]

Interesting, that has been my subjective experience too. JFS on a s/w raided scsi system seems slow, and is audibly thrashing discs - I have been thinking about switching back to xfs (which I have been using for some time, and seems fast and reliable).

Are we missing any tuning here?

Re:This is kinda weird

[insomaniac]

Maybe but my opinion of jfs is not so good atm, if someone would know why this is, I would greatly appreciate any possible explanation for this.

Re:This is kinda weird

[merdark]

I had JFS running on a gentoo installation as well. I found it to be very fast. When writing small files, I found it subjectivly faster than XFS.

I don't use reiserfs due to my lack of confidence in it's recovery ability. The only time I tried it, it crashed hard and even the repair tool couldn't fix it. Also, this seems to be the experience of many others who don't support reiser and the reason that Redhat decided not to support reiser. I guess that so long as you have no problems, reiser is fine.

Re:This is kinda weird

[karlm]

Your laptop HD is probably 5400 RPM or slower. Resierfs did poorly in these benchmarks primarily because it uses a lot of CPU cycles to get good performance. If you have spare CPU cycles, but your HD is being taxed to the max (as is especially likely in a laptop), Reiserfs will probably work well for you.

Re:This is kinda weird

[insomaniac]

Thank you for that, that would explain it as my hd is indeed 5400rpm and my cpu is an amd xp1800+.

Irrelevant numbers

[krorvik]

These benchmarks were performed on relatively old hardware, with a slow cpu and a disk only running UDMA2. And, as others have already pointed out, the data are statistically not really reliable.

Myself, I'd be much more interested in seeing numbers made on a setup more like my own.

Static benchmarks are never good for deciding "which is best".

Re:Irrelevant numbers

[BenjyD]

These benchmarks, by the guys who host most of Gentoo, were done on a dual 2.8Ghz P4 Xeon's, 2Gb of RAM machine (Dell PowerEdge 2650) and (AFAICS) reach broadly similar conclusions - 'best' depends on your usage, but JFS is pretty good, reiser uses a lot of CPU etc.

Re:The only one that matters

[black mariah]

Think before you flame? You do realise how stupid that statement is upon further review, correct? ;-)

Re:Cheaters interested in MS FS's?

[im a fucking coward]

I hate to point out the blaringly obvious, but who did the test? Linux kernel group. Can linux be run native on MS FS's? Nope. Ergo, any test you're going to run cannot be relevant in a direct comparison.

Additionally, any access to MS FS's from a linux OS is reverse engineered, certainly not MS certified/sanctified, and would therefore be horribly unfair to them.

The more interesting question to ask here is why doesn't MS have these types of tests published? Where are the comparisons on database, file/web/app servers? They do them, but you'll never see them posted for rather obvious reasons. (If you have to ask, then you should consider how much of a deficit running the gui from kernel space inflicts on a server right off the top.)

there is more to a filesystem that speed.

[msh104]

every filesystem has its own purpose, for example reiser4 has atomic operations, database like capabilities, journalizing and metadata. now how are you going to say that ext2 is better because it performed better in brenchmark xyz. this is just the same thing as people buying a graphics card because it scored 1 or 2 fps more then an other card but forget that the other card has a build in mpeg2 or for the same price.

Re:there is more to a filesystem that speed.

[LNX Flocki]

Remember that this was a "perfomance test" not a "which FS is better" test. Benchmarks only show you which one is faster at specific tasks, it doesn't necessarily tell you which one's better.

what about vxfs

[xyloplax]

Too bad VxFS is commercial and the benchmarkers probably could not afford it; I have had great experiences with it.

Re:what about vxfs

[codepunk]

Yea what is so good about it, on solaris it is cluster capable on linux it is just yet another file system. Besides that it is veritas and I have not found a single good thing to say about these guys and linux support. Hell even the backup exec agents are unix and still not supported by them. I would not buy anything from these guys again, they talk the big linux game but I see very little results.

Re:what about vxfs

[xyloplax]

True indeed. I forget that my experience with it is Solaris+Oracle. That's just sad if that's their idea of "linux support"

Reliable Filesystem

[Anonymous Coward]

I don't know about other people but for me reliability is FAR more important that speed. In my house my computer gets bashed around, we have power cuts, ocationally someone pulls the cord e.t.c. I want a filesystem that I know will not break and preferably even be able to cope with minor physical errors appearing on the disk!

Sort of on topic...

[blixel]

I have a new 200GB hard-drive on the way that will be here any day now. I plan on using this new drive as a storage drive for music, digital camera images, documents, bookmarks, settings, game save data, e-mail messages, backup data, and so on. If WinXP or Linux irreparably crashes on me, this storage drive (and it's mirrored backup) will contain all the data I care about.

I have two different physical drives in this machine now and I dual boot between them. Linux (for just about everything I do) and then WinXP (for things that absolutely require Windows.)

The new drive I'm getting will be hooked up to my machine externally via Firewire. (I don't need help with the external setup. I already have another drive hooked up this way and it works just fine.)

Now my question is - what is the best file system to use for compatibility between Windows XP and Linux. I require full read/write access to this drive whether I'm in Linux or WinXP. I know NTFS is out. (Even with the 2.6 kernel, write support from Linux to an NTFS partition is limited [can't create new files or directories] and Linux NTFS writing is not considered completely safe.)

I'm guessing VFAT is my only option but I thought I would ask around first.

I do have another machine laying around but I don't want to set it up as an NFS/Samba server for a few different reasons. #1. I don't want to leave the machine on 24/7. #2. I don't want to tie up that machine. I like experimenting with new things so if I turned that machine into a full time server, I wouldn't have a test bed machine any more. #3. I don't like NFS.

I have also thought about one of those Network Area Storage systems. Maybe someday, but at this point in time that idea is out too.

Does anyone have any experience with this? What solutions have you come up with?

Re:Sort of on topic...

[gl4ss]

Fat32?

Re:Sort of on topic...

[PReDiToR]

Make it whatever you want and mount it in a VMware machine if you aren't bothered about the speed from one of your operating systems.

Yeah, I know, VMware is for people who don't have the balls to switch to Linux full time, but it makes interoperability 100% successful if speed isn't a concern.

VMware site.

Re:Sort of on topic...

[rezza]

Yeah, I'm in a similar situation... I've been thinking about it for a while, and the only viable option really is FAT32 at the moment. There are some rudimentary ReiserFS drivers for windows, but they're all read-only unfortunately. My problem is that I already have around 120 gigs of data sitting on an NTFS partition, and I really don't want to risk an NTFS->FAT32 conversion on it... I think I might end up just waiting for stable NTFS read/write in Linux... although ideally I'd prefer my data to be on a native Linux partition (since thats the OS its going to be accessed most from). Options are very limited at the moment unfortunately.

Re:Sort of on topic...

[Jameth]

If you can afford a little extra partitions, try reiserFS. Although it is not natively a part of windows, there are tools which let you use it. This means you cannot install windows on it, but you could get read-write access with it.

Back when I still dual-booted, I had this layout:

5 gig NTFS WindowsXP partition
5 gig XFS Slackware partition
1 gig swap parition
45 gig reiserFS shared storage partition

This also made me feel a lot safer in using the systems: Neither ever mounted the other system's Root directory, so all that was actually shared was what I used as my home directory. No matter what I did on one system, even if data corruption happened, it would never be so bad that I couldn't boot it. (Note: I never had data corruption, it was just a mental comfort issue)

Re:Sort of on topic...

[angle_mark]

There are some free and some commercial products which can offer full read/write + journalling access for ext3 partitions from Windows. I'd definitely recommend you pick ext3 over fat32.

Some examples..

Free: Explore2fs allows you to read ext2 and ext3. Limited write support is available.

Commercial: Ext2FS Anywhere don't let the name put you off as it has full read/write support for ext2, ext3 and I think reiserFS is supported now too.

Re:Sort of on topic...

[blixel]

My problem is that I already have around 120 gigs of data sitting on an NTFS partition, and I really don't want to risk an NTFS->FAT32 conversion on it...

What sort of risks? I have about 120GB on an NTFS drive also. I was planning on formatting the new drive as FAT32 (VFAT) and then just copying one drive to the other. I assumed the Operating System would handle the conversion? Just like if I were copying from EXT2 to NTFS via Samba over a network share.

Re:Sort of on topic...

[blixel]

Thanks for the links... that commercial one is definitely worth considering at only $29. The free one sounds sketchy though... not being actively developed any more.

The drive I'll be storing this data on is external though. So part of me wants to use a native Windows file system so it can be more portable. I'll have to mull over that one.

Re:Sort of on topic...

[rezza]

Yeah copying/moving would be fine... I'm talking about actually converting the partition in-place from NTFS to FAT32, which has been known to be slightly risky. Might be a good idea to just get another drive and do it your way...

Re:Sort of on topic...

[blixel]

I'm talking about actually converting the partition in-place from NTFS to FAT32

Ah... yeah I wouldn't even try something like that with data I cared about. Sounds like a disaster waiting to happen.

I don't trust repartitioning in place either. Hard-drives are too cheap these days. I mean what does a program like Partition Magic cost? $70 or something? I bought a 120GB Western Digital 7200RPM IDE drive w/ 8MB of cache for $59 after rebate. (Rebate check arrived within 3 weeks.) Seems like a better investment to me.

Re:Sort of on topic...

[swv3752]

Or go with http://www.ntfs-linux.com/

Which is the paragon software for the linux side of things. The mount-anywhere is $39 and then you get the best of everything for personal use.

Re:Sort of on topic...

[blixel]

Which is the paragon software for the linux side of things.

Is it reliable? And if so, how is it that some 3rd party company can make a simple little program that can read NTFS from Linux when a group of developers around the world haven't been able to do it?

Re:Sort of on topic...

[Anonymous Coward]

Good question. I bet they work for Microsoft.

Re:Sort of on topic...

[el_chicano]

Yeah, I know, VMware is for people who don't have the balls to switch to Linux full time

Actually VMware is perfect for full time Linux users who haven't managed to get rid of the Windows monkey on their back...

Re:Sort of on topic...

[PReDiToR]

I see your glass is half full =)

Re:Sort of on topic...

[swv3752]

probably signed some sort of NDA.

Mod parent +3 funny

[im a fucking coward]

I was just BS'ing with the Big Blue Ballz, and they've been actively developing JFS for linux for quite a while. Why? Check here:

http://mozillaquest.com/Linux03/ScoSource-24-Cop yr ights_Story01.html

Or: "SCO-Caldera also admits that it does not own the copyrights for the JFS, RCU, and NUMA software code that IBM contributed to the Linux kernel -- or other IBM-developed AIX code that IBM contributed to the Linux kernel."

Sorry, I don't have cohorts @ SGI, or I'd try to take issue with XFS ownership as well. SCO's 'ownership' will surely relegate it to a meaningless death.

Re:The only one that matters

[Wolfrider]

--NFS? Http? Ftp? Bah! What are these things to me? I just use netcat. ;-b

All Pathetic

[Jon_E]

~15-20MB/s best case sustained for a sequential write? You might want to baseline this with raw performance, take a look at IOPs amd filesystem layout for a particular application, adjust the blocksize and take an approach like what's laid out on http://www.storageperformance.org/ ..

Re:All Pathetic

[TheCrazyFinn]

Did you look at the system they tested on?

It's a low-end P-II running a 6.4GB UDMA33 Drive. Those are damned good numbers for it.

file size a problem?

[twitter]

If 30 33.3MB files (bonnie test) are not representative of your needs, please download the scripts. You can then modify the parameters for thousands of 2k files and post the results. Lots of people would be intersted, you know.

How about a clustered fs shootout ...

[ItWorkedLastTime]

Y'know - GFS vs OpenGFS vs OCFS vs OpenAFS etc Problem with these benchmarks is they're out of context - there's never going to be a clear winner in all categories. Small number of big files/large number of small files, mostly reads/mostly writes, mostly random/mostly sequential access. And when you chuck in robustness and performance, it's even less clear. Please could someone come up with a set of application-specific fs benchmarks - departmental file server/app server/database server/mail server/web server - and do a clustered version to boot?

Same problem in Safari

[AnEmbodiedMind]

Safari silently gunzips it and saves it to the desktop.

Worth Noting

[MajroMax]

It's worth noting here that the benchmarks were all run on files >= 1GB, if I'm reading the table correctly; this stresses the raw IO of the system, and doesn't really take into account the differences in tree-structure between the filesystems.

As for complaints about Reiser's performance -- last I heard, it was more optimized for many small files -- precisely the domain that this thing didn't test.

Re:Worth Noting

[Anonymous Coward]

Agreed. Raw transfer speed is nifty, but how often do I ever do that?

I'd much rather see benchmarks for the tasks a workstation does- compiling, searching mail, multiple tasks at once.. etc.

Re:Worth Noting

[Tin Foil Hat]

As for complaints about Reiser's performance -- last I heard, it was more optimized for many small files -- precisely the domain that this thing didn't test.

And we all know that all Linux distros have one thing in common: like all *nixes, they're made up of an enormous amount of small files working together. Precisely why ReiserFS is so popular these days.

unfair?

[FatSean]

Come on! What are they going to say "Linux makes our filesystem look bad because we won't tell the developers the most efficient way to interface!"

Oh boo-hoo! :)

Re:unfair?

[im a fucking coward]

Come on! What are they going to say "Linux makes our filesystem look bad because we won't tell the developers the most efficient way to interface!"

Jeeez, give me a break! So the point that the test will be obviously meaningless doesn't strike you as good enough reason not to bother? How about the fact that Torvalds doesn't work that way, there's a goofy chivalry he reeks of like cheap aftershave, and it's so strong that the kernel minions are pickled with it.

Even assuming my assertion's are total crap, the link provided has the scripts for running the tests. Download 'em, set up the file systems, patch the NTFS write cabability for your kernel, and plow through 'em. Just don't forget to post the results, I'd like to see what you come up with! If you do, I'll do the same on my cheap a$$ed 1.3 Duron .5 gig RAM 7600 RPM WD HD to help nail down the/any HW deviation.

PS: I sincerely doubt there's a chance that the scripts will even work on that setup, but if you succeed, I'll give it a whirl.

Re:The only one that matters

[Anonymous Coward]

samba is not a file system.
so the performance of a filesystem should be measured by it performance with samba because many linux servers have to serve windows clients? not surprising you think that way considering your name.

Re:The only one that matters

[kasperd]

I just use netcat.

When transfering lots of data between two computers nothing beats netcat. I use it for my backups:

nc -l -p 200 > home.$(date +%s).tgz
tar -cz /home | nc backupserver 200

But for accessing the same /home on different computers I still use NFS.

Anyone have a link to results with ntfs?

[Anonymous Coward]

It's a comparision that many, like myself, are interested in. That they removed the results that already spent the time to do seems to indicate they didn't care for people to see Linux's poor showing.

bonnie++ comparison between reiser4 and ext3

[nikitad]

I should probably add that I am getting quite different bonnie++ results for reiser4 vs. ext3.

They are available at reiser4 benchmarking page along with
hardware specifications.

http://www.namesys.com/benchmarks.html#bonnie++.20 03.09.30

Re:The only one that matters

[Anonymous Coward]

It must be hard running a network of 2 boxes without samba in your home... what do you do in your spare time. Oh, don't tell me, let me guess - you post to Slashdot.

p.s. what did your mom say when you told her to use KDE instead of XP?

Re:human readable ? Reiser vs ext3

[cyber_rigger]

Reiser is nice until it crashes (power failure).

I've had one reiser file system failure.
I use ext3 now. I haven't had any problems with it at all.

Slow is infinitely faster than not at all.

Re:The only one that matters

[EvilAlien]

"pur sang"?

Try "perse", its Latin and means what you were trying to say, versus pur-sang which is French for thoroughbred or pure-bred.

Re:The only one that matters

[mark_lybarger]

But for accessing the same /home on different computers I still use NFS.

i've tried this in the past, but had major issues when one of the boxes would be brought down/rebooted. NFS didn't seem to like to recover very well. Is there a way to set a timeout for accessing a NFS mount? All my processes accessing the share basically hung, and i couldn't unmount the share as there were processes accessing it. finding the prcessses manually and manually killing them was a bitch. I know when i try to access a network device using Windows that if the share isn't there, it seems to timeout....

Quote from Ted Unangst about filesystems...

[Anonymous Coward]

you will use the one true file system, ffs, and you will like it, waking up each morning with the clear conscience of a man who doesn't worry if he really picked the right journaling file system, or if maybe ext3fs wasn't a better pick, or jfs,
or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the beginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :)

Re:Cheaters interested in MS FS's?

[ckaminski]

(If you have to ask, then you should consider how much of a deficit running the gui from kernel space inflicts on a server right off the top.) In all honesty, when NT 4 moved the GUI into kernel space, 99% of the bitching wasn't that it slowed performance, or even improved it, it was that it made NT less robust. On a server, you're never going to USE the GUI, so it's presense in the kernel only reduces stability in the event that Administrator on the console or the remote RDP session fucks something up. So now I hear this rumor that Longhorn's moving the GUI back out of the kernel. Any truth to that?

FAT32 all the way

[Gothmolly]

But format it on the Linux side, Win2K+ has an annoying 'feature' that it won't let you make FAT 32 partitions over 32 GB, "since you should move to NTFS anyway". I had this fight long ago, the only better alternative is HPFS, which you had to hack into NT 4, and was removed in Win2000.

coprehensive comparison

[PapaZit]

Sigh. Another benchmark where only speed was compared.

I want to see a feature benchmark where speed is one consideration, but not the only one. How about maximum file size (who would ever use a FS with a 2GB max file size?), resize-ability (important for LVM users), minimum partition size (matters for ramdisks, etc.), minimizing reads/writes (for flash memory), etc.?

Re:The only one that matters

[TheCrazyFinn]

Which is why Samba rocks.

It may have it's issues, but it's far more robust than NFS, which has major issues with access control, locking and machine availability (Although I understand NFSv4 addresses the file locking issues). SMB/CIFS which was intended for an unreliable of DOS machines, handles machine availability much better, and also handles user-level authentication and ACL's. NFS uses machine-level authentication and lacks robust ACL support.

NFS does have it's uses for providing filesystems to Diskless workstations, but that's it.

Now I understand there are some very nice Network File Systems with support in Linux, that far exceed SMB in features and performance, but I haven't played with them.

And the solution to poor network performance with SMB enabled is to set up one of the Samba boxes as a WINS server, and use WINS instead of broadcast name resolution.

Some suggestions for future tests

[cluge]

These numbers are great, but only tell us a little about reliability or "real world" performance. When I did testing on these file system I used all the benchmarks here, plus a benchmark called postmark. This benchmark utility was released into the public domain by Net App and has to be one of the better "real world" benchmark suites.

The problem that we had with JFS during testing is that we had kernel panic with very large files. Thus we chose XFS - which has done an excellent job. I'm sure glad that the XFS file system has been merged into the 2.6 kernel, no more patching the 2.4's!

For more benchmarks on other file systems using postmark check out This

Re:Some suggestions for future tests

[IpSo_]

This is the wonderful thing about open source. You can easily download the scripts used to generate those results, and add postmark support to them. The scripts are made in such a way that adding file systems and benchmark programs is very easy.

Re:The only one that matters

[Mr Z]

Look into -o intr and/or -o soft for your NFS mounts. From the man page:

hard

• The program accessing a file on a NFS mounted file system will hang when the server crashes. The process cannot be interrupted or killed unless you also specify intr. When the NFS server is back online the program will continue undisturbed from where it was. This is probably what you want.

soft

• This option allows the kernel to time out if the nfs server is not responding for some time. The time can be specified with
• timeo=time. This option might be useful if your nfs server sometimes doesn't respond or will be rebooted while some process tries to get a file from the server. Usually it just causes lots of trouble.

Note that the statements "This is probably what you want" etc. in the quoted text above come from the man page, not me.

--Joe

MOD PARENT UP

[Anonymous Coward]

This is VERY VERY important. Last time I tried using reiser, it got broken in 6 months, and reiserfsck didn't fix shit.

How good are the repair tools for all of these filesystems? And what is the probability the filesystem will get messed up?

--Coder

this benchmark was performed using a 200Mhz CPU

[hansreiser]

which makes the whole thing pretty questionable in my view, especially when you consider that Nikita got completely different results on his more modern hardware (see www.namesys.com/benchmarks.html)

I don't really target 200Mhz CPUs in my performance tuning....;-)

Hans

Re:this benchmark was performed using a 200Mhz CPU

[YetAnotherDave]

Benchmarks aside, I've been running reiserfs on all my boxes since kernel 2.4.5, and I've been completely satisfied with the performance both speed-wise and in terms of recovery after powerfailures.

Thanks Hans

Re:this benchmark was performed using a 200Mhz CPU

[Deagol]

How true a difference the hardware makes.

I took an old PII-350 w/ 128MB RAM and benchmarked ext2, ext3, jfs, reiserfs, and xfs on an old 5GB IDE drive. ext2 was the winner by a margin (raw throughput).

Now I'm beating up various hardware and software RAID configs on a dual Athlon MP 2200+ system w/ 2GB RAM and dual 3ware 8-port 7500 controllers w/ 180GB WD drives. JFS rises above the rest in terms of throughput (I didn't test XFS on this new machine), and, of course, reiserfs simply spanks everything in terms of file creation/deletions. The thing I noticed was the JFS had much lower CPU utilization for file creations/deletions and was twice as fast at it than the ext2/3 filesystems (it still got spanked by reiserfs, though).

If anyone's interested, the "best" overall was reiser w/ the mount options noatime,notail,nodiratimeall. Also, if anyone cares, on this machine, the Linux software RAID code at no less than twice the performance numbers over the 3Ware hardware RAID. Running RH9 with all RH updates applied.

Re:this benchmark was performed using a 200Mhz CPU

[tzanger]

I've seen that too -- linux software RAID (RAID1) absolutely spanked my DPT 2044UW2 RAID controller on an aging P2/233. On this P4 I'm also using software RAID since I've definately got CPU to spare and UW3 disks.

Re:this benchmark was performed using a 200Mhz CPU

[JonR800]

So wait.. you're saying the software raid was twice as fast as the hardware raid card? That seems kinda crazy to me. How would you go about hooking up like 16 drives anyways?

Re:this benchmark was performed using a 200Mhz CPU

[Anonymous Coward]

He's correct. I have tested Linux software RAID mode against several IDE-raid options in my P4/3Ghz system, and the result of all of them was that software RAID was much, much faster than any of the hardware solutions (and a hell of a lot less cumbersome to set up).

Offhand I would attribute it to the puny, useless CPU power most of the RAID cards have compared to the relatively beefy Intel. Also, most cards seemed to have little positive or negative effect to having on board cache RAM (the Adaptec 2400A literally didn't care; put more cache on, net zero difference in testing).

Re:this benchmark was performed using a 200Mhz CPU

[Anonymous Coward]

Hardware RAID manufacturers have been almost exclusively banking on the fact that their customers are looking for mirroring and not improved performance (or at least, appeased by not much extra performance). They've never actually had competition like this before, so they're losing horribly.

Re:this benchmark was performed using a 200Mhz CPU

[sethml]

Um, no it's not. If you look at their web page, it's a 450 MHz PII:

vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 2
cpu MHz : 451.018
cache size : 512 KB

In fact, I'm pretty sure it's a Pentium II Xeon (the server version of the processor), since the desktop processors have only 256K of cache. My machine at home happens to have two of the same PII Xeons:

vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 3
cpu MHz : 448.058
cache size : 512 KB

So, while it's not speed monster, this is not that slow of a CPU.

Re:this benchmark was performed using a 200Mhz CPU

[Anonymous Coward]

vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 2
cpu MHz : 451.036
cache size : 512 KB

From my PII-450 (non Xeon).

PII's had 512KB of half-speed L2. PII Xeons came in multiple sizes of L2, the smallest being 512KB (which is apparently what you have). The advantage of the 512KB Xeon over the regular PII is that the L2 runs at full speed.

The PIII changes to 256KB of cache, at full speed. PIII Xeons are just regular PIII's with bigger caches.

Re:The only one that matters

[4of12]

In a LAN environment, NFS is fantastic for keeping down support costs.

In particular, install some package in /usr/local on the server and instantly it's available to a couple hundred clients that import that filesystem.

Home directories that are up 24x7, so that everything looks exactly the same no matter which workstation I log into, doesn't matter if it's "mine" or if "mine" is off.

All NFS needs is a good network and a reliable file server.

It's worked for me for over 10 years now.

I am looking forward to the improved security model in NFSv4, though.

NTFS read/write in Linux

[sethadam1]

Don't count on this. The write (and maybe read) drivers will always be "experimental." Why?

Because NTFS specs are locked in a dark closet in near Seattle never to be seen by the evil Linux developers. These developers, fearing for their lives, will never have the guts to deem their NTFS write stable - there will always be a slight chance you'll corrupt your entire disk table - and no one wants their so-called "stable" driver to corrupt people's data.

In NT4, NTFS was at version 1.1, aka NTFS 4.0 (to align with NT4.0). In Windows 2000, it was version 3.0, aka NTFS 5. And in XP, it's version 3.1, also known as NTFS 5. The point is, NTFS is a moving target, so it's unlikely we'll see effective NTFS abilities in Linux anytime soon.

um...FAT32 *is* VFAT [nt]

[sethadam1]

text to get past lameness filter

Re:um...FAT32 *is* VFAT [nt]

[gl4ss]

err.. no it isn't. well.. fat32 came in osr2 of win95(most notably it allows bigger than 2gb discs).
http://www.winnetmag.com/Articles/Index.c fm?Articl eID=4489

** Don't confuse FAT32 with VFAT. VFAT is not a file system but an enhanced file system driver for use with NT and Win95. It functions as an overlay to the 16-bit FAT file system commonly found in DOS. If you plan to dual-boot NT 4.0 with any current beta release of Win2K, you can obtain a read-only FAT32 driver for NT 4.0 from Systems Internals (http://www.sysinternals.com).

Another important FAT32 feature that NTFS already implements is that it uses smaller allocation unit sizes and a smaller cluster size than FAT. This configuration results in 15 percent more efficient use of disk space. Slack space occurs when an allocation unit has part of a file or a whole file that doesn't take up the full allocation unit and the remaining portion isn't available for storage. Some OSs, such as NetWare, work around this slack-space problem through block suballocation.

FAT32 provides more file system stability than FAT. Microsoft expanded the boot record on FAT32 drives to include a backup of critical data structures. FAT32 can also maintain multiple copies of its File Allocation Table. In the event that the first table is corrupt or unavailable, FAT32 relocates the root directory and uses a backup copy of the File Allocation Table. FAT32 doesn't restrict the number of entries that can appear in the root directory. However, 16-bit FAT limited the root directory to containing 512 entries of directories and files. This limitation led to Out of disk space errors when a user attempted to copy a file to the root directory, even if the directory had 800MB of disk space available.**

Re:The only one that matters

[TheCrazyFinn]

Oh, yeah. NFS doesn't suck, it's just got some issues that Samba doesn't have (And vice-versa). Exporting filesystems to unix clients is one of the advantages of NFS.

Exporting private shares, and common work directories is handled better by Samba though.

Another grammatical correction

[sithkhan]

Well, I hate to kick a man while he is down, but

its Latin and means what you were trying to say

should read

it's Latin and means what you were trying to say

... Sorry to give you the double whammy ...

Re:The only one that matters

[TheCrazyFinn]

Interesting.

Nice to see that NFS has addressed the Infamous 'Sun Network Lockup' issue, where networks with a lot of cross-mounted filesystems would die in a cascade of lockups if a fileserver died.

SMB of course addresses that problem inherently.

Some clarification...

[IpSo_]

First off, let me just say that benchmarks are really only good for people to compare their _own_ benchmarks too. If you really want to know which file system is fastests on your desktop/server, you need to run your _own_ tests. Don't rely on anyone elses results.

EXT2 was included in the results as some people say for a baseline in which to compare the journalling file systems to. I personally wouldn't recommend using EXT2 on any system, unless you have very specific needs that require it.

Keep in mind that Bonnie++ and IOZone benchmark programs are quite different. JFS was not a good performer as far as raw speed was concerned using Bonnie++, but it did use very little CPU, so overall it performed relatively well. If your applications bottleneck is your disk, JFS would be a poor choice as far as bonnie++ is concerned. If your applications bottleneck is your CPU, JFS would be a relatively good choice. However the IOZone results show a completely different story, so again, you need to figure out which benchmark more closely mimics your own needs, and run your own benchmarks!

I would also like to note that Reiser4 is an atomic file system, which I've heard offers the same reliability as EXT3+Journal, so for a "fair" comparison, it should be compared directly against EXT3+Journal, and it mops the floor against it. Also keep in mind Reiser4 is still in its very early stages, so the comparison isn't exactly "fair" anyways, it will be a file system to keep an eye on in the near future without a doubt.

Lastly, the benchmarks were run on a PII-450 (as the hardware link states) which I fully realize is completely out dated hardware, so although Reiser4 uses a lot of CPU in comparison, on the more modern CPUs its not nearly as bad for some tests.

JFS on a GIS map server.

[Nick Driver]

I've set up JFS (SuSE 8.2) on a Proliant ML370, dual 2.8GHz Xeons, 2GB memory box with a 300GB raid5 array on a SmartArray 5302/128 controller for a GIS map server (lots and lots of files served via Samba, most files in the several tens of megabytes size) and it is literally twice as fast as when that same box was running WinNT4SP6a. The owners of that box were skeptical of Linux at first, and were hardcore Windows fanatics, but between myself, and their tech guy at the GIS software vendor, we talked them into giving Linux a test drive on this new server hardware. One day into the test, they were sold on Linux. I was torn between choosing XFS or JFS for the 300GB Samba-served filesystem, and finally settled on JFS, and it looks to have been a good choice based on the kind of traffic this server sees. We've had zero problems and it's been running 24x7 since mid-August... about two months now. Uptime is 68 days today.

Re:JFS on a GIS map server.

[Anonymous Coward]

Really, you'd probably be better off with XFS for large file sizes (I'd say that anything over 10MB, but especially 100MB+), if your dataset ever grows past 300GBs, or 5+ disks.

Where XFS really shines is on *BIG* RAID or Fiber Array systems, where reliable throughput is necessary. There's not much of a point running XFS on any single disk system, unless you're using it for it's journaling ability... Something these testers failed to realize.

With a decent machine (certianly your machine classifies), it would not be unreasonable to get 130MB/s + reads and writes on a fairly loaded system (with a good RAID setup, of course). With that kind of transfer rate, over a Gb link, Samba is going to be a real system hog. But, that's what a Samba server's all about, I guess.

If it's pure file server, and you don't need to write from the clients, you might be better off with another protocol (even HTTP would be more efficient).

Most important: Work/CPU % column

[Futurepower(R)]

It seems to me that the important measure is the speed per unit of CPU power, not the speed alone.

Even if you have a single-user workstation, you don't want to just sit there while the computer completes a previous operation. That's what would happen if the CPU utilization were high.

So, the most important number is the Work/CPU % column. That column shows the true efficiency.

Second, fully journalling file systems cannot be compared with those that do less work and offer little safety.

Re:The only one that matters

[ktulu1115]

I'm wondering if anyone either has real-world experience or benchmarks on optimium filesystems/partitions for a Linux workstation (the usual: web browsing, games, multimedia, etc)...

I'm thinking about the following (planning on switching back to Linux sometime soon hopefully):

/home - JFS (fast but still has journaling support)
/etc, /usr - ext2 (mostly read-only operations, correct?)
/var - ext3, maybe JFS... still thinking. Like to run a database & webserver but only for my own use (practically zero load)

Any comments?

Re:The only one that matters

[ePhil_One]

Why on earth would you use 3 different filesystems? Hoping to maximize your failure rate?

I like JFS. In the past it didn't get along with NFS very well, but that seems to be fixed for over a year now. But your far better off picking a single FS and sticking with it, except possibly /boot, than doing a different filesystem each partition.

Graphs Anyone

[Milican]

Great info with the numbers. However, I'm wondering if anyone has graphs out there for these or similar benchmarks...

JOhn

spooky

[kayen_telva]

Until I can ghost it, it aint going on my drives.

reiserfs strangeness

[hqm]

http://www.ussg.iu.edu/hypermail/linux/kernel/01 09 .3/1579.html
Look at this thread, there is some miscommunication about what exactly protection is provided by reiserfs in the face of unexpected system shutdown ; note that they seem to have a problem with file content corruption due to lazy writebacks.

Use a graph please...

[jakesher]

Human readable bleh. I don't have all day to peruse a spreadsheet....create a graph or two....bleh.

Re:The only one that matters

[Mr Z]

Actually, I think 'intr' and 'soft' have been mount options for, oh, say a decade or more?

Personally, I think a -o hard,intr mount is probably the right choice for most network mounts, and a -o soft mount is a polite option for remote, readonly filesystems shared by a larger crowd. (Almost nobody does that anymore. I believe wuarchive used to offer a read-only public NFS mount around 10 years ago.)

--Joe

Well... typical?

[non-poster]

Ok, so where's the "human readable"? There is no analysis, conclusions, or anything else except raw numbers. There are no rankings, no sugestions, just numbers. Also, the test was run on a Pentium II, 450MHz, 512MB of ram and a 6.5GB IDE disk, 5400 rpm, 256kb cache, and 3 heads (=4gb/platter). This is nowhere close to current technology. You can't even buy this hardware any more! I would have much rather seen a 1-1.5GHz CPU with a 40GB hard disk used in the tests. The amount of memory is adequate, though.

Re:Well... typical?

[Frit Mock]

What hardware used doesn't make much difference, when benchmarking the efficency of different filesystems. The relarions between these filesystems will not vary much.

IT's like with every "test" ... a specific test scenario, will not neccessaryly reveal what _you_ want to know.
Download the scripts and setup _your_ test-scenario, then _you_ will get the results _you_ are interested in. ;)

NTFS to FAT32

[sethadam1]

You can't convert NTFS to FAT32 without a 3rd party tool like Partition Magic. Now, I'm not sure about PM > 7.0, but as late as 7 it would still generate errors. Here 's more on that

Here's another discussion from some people with alternative methods.

Different results when using RAID devices

[Anonymous Coward]

I did some filesystem benchmarks myself and found that JFS performed well at raid levels 1 and 10, but XFS totally dominated on RAID5. At least when using dt as a benchmark program. I also ran IOzone, but do not have the results in a form that I can easily compare them.

Re:The only one that matters

[ajs318]

2 boxes per room at least, actually.

And my mother had been using KDE for eight hours before she even noticed it wasn't Windows.

Re:The only one that matters

[0x0d0a]

I'm wondering if anyone either has real-world experience or benchmarks on optimium filesystems/partitions for a Linux workstation (the usual: web browsing, games, multimedia, etc)...

Just about all of the filesystems are excellent. Frankly, the degree of tweaking people do to try to maximize performance is ridiculous. These are all good filesystems, and none of them drastically better than the others when it comes to performance. This is *especially* true when you're just using the thing on a plain ol' vanilla workstation, where the load you put on your filesystems is essentially nonexistant.

I'd make my decision based on features.

I suspect most folks want journalling support. It's an awfully nice feature to have. So probably ext2 isn't a great choice for them. You can easily migrate an ext2 filesystem to ext3, so if you're currently using ext2, ext3 is definitely the way to go. Reiser can deal particularly well with non-empty-but-extremely-small-files, and drastically reduces space usage for such files. Source code doesn't take as much space (percentagewise) of a drive as it used to, but it might be a valuable consideration for developers). XFS had a fairly specific design goal (and here I will delve into performance, since it has a particular specialization) -- streaming files linearly.

I'm not sure what unique features JFS has, since I haven't played with it.

*bop*

[Anonymous Coward]

That's what the benchmark script is for! Test it out on your own system, and let us know what you get ;)

Do we have another holy war here?

[GNUALMAFUERTE]

If you don't stop with this "my fs is better than yours" think i will go over *your* place at night and put your / on an umsdos and your home on a fat16, so shut the fuck up or you will end crying : - )

Better Title: How an FS works with Samba

[ashitaka]

Exactly. For my Samba boxes I want a filesystem that is fast, fault-tolerant and can support proper NT-style ACLs without too much dicking around.

Recommendations?

Eh.

[Tukla]

Until Reiser 4.1 comes out, I'm just making do without a filesystem.

Re:Eh.

[drfreak]

Really, those pesky filesystems just get in the way. Just cat file >>/dev/hda and be done with it.

Re:The only one that matters

[etcshadow]

Of course samba is a file system (or at least, there is a samba filesystem for linux). What are you talking about?

$ man smbmount
SMBMOUNT(8)

NAME
smbmount - mount an SMB filesystem ...

or how about:

$ grep smbfs /etc/fstab
//otherhost/public /mnt/otherhost-public smbfs ro,... 0 0
//otherhost/private /mnt/otherhost-private smbfs rw,... 0 0

Now... whether it makes sense to talk about benchmarking it in this sense is another thing all together. Granted, it would make more sense to benchmark smbfs versus nfs or afs (where you carefully controlled other hidden variables in the comparison, like network speed and the underlying filesystem on the remote host) then to benchmark it versus ext3 or reiserfs... But it is still incorrect to say that samba is not a file system.

Is nfs not a filesystem? If so, they really chose a poor acronym.

Re:Hey Joe

[Anonymous Coward]

With apologies to Mr. Hendrix.

Why single Jimi out? His may be the definitive version, but it's not like he held the copyright or anything.

Hardware issues?

[Grayputer]

Did anyone else look at the hardware? A single CPU PII 500, half gig ram, and a single 5400 RPM IDE drive for OS and test data.

Usually a benchmark has a goal, I/O per sec, read or write data throughput, or some set of criteria. Once the criteria are spec'ed then hardware is spec'ed to avoid 'getting in the way'. If I/O throughput is the issue why not SCSI or hardware RAID or some other hardware that would improve the hardware throughput and be representative of what someone in the field might actually use if I/O bottlenecks are a concern. If data bandwidth is an issue use RAID (1 or 5, depending on write or read optimization). If the test is actually testing overall filesystem performance, at least separate OS and data drives and use something faster than a 5400 IDE drive for the data.

What are we benching? Usually a bench is either checking for best performance on a fixed hardware platform (application oriented, my app runs on X, what is my best option to squeeze performance) or best performance period (tweak hardware for each FS and report best config and the performance at that config). Assuming a fixed hardware platform test, I'm confused why this platform. Is this the platform for a Linux DB server?, a POS environment?, a Web server?, a dev machine?, something found left over in a garage?. WTF is the PURPOSE of the bench? Geez, just upgrade to a 1 gig processor and a hardware Raid-5 controller with 4 15K SCSI spindles and choose the FS randomly to get better performance. And NO you CAN'T tell me this result RELIABLY predicts performance on the new platform (slow IDE vs. fast SCSI, non-raid vs. raid-5), at best it is an indicator of what to re-bench in what order.

So I'm back to being confused, why do I care about these numbers?

Re:Hardware issues?

[statichead]

What he said! ^

Metadata usage?

[strredwolf]

Does anyone know about metadata usage? I think some folks will want to know how much the filesystem of choice is taking up just for tracking info.

Re:The only one that matters

[Newander]

If you read carefully, you'll notice that the name of the filesystem is SMB. Samba is software that interfaces with the SMB filesystem. Of course, SMB isn't really a filesystem either. When you want to share something you don't have to create and format a partition as SMB.

Re:The only one that matters

[Anonymous Coward]

Your mom's basement/sex dungeon is one room.

2 boxes, 1 room = 2 boxes per room.

And now for some spam fun:

sd_resp@groundfloor.adyx.co.uk

Warning: JFS is not fast.

[Tisephone]

It may have a lot of pretty green boxes, but if you look at the columns on the far right, it's often slower then ext3 and never faster then ext2.

Re:Another grammatical correction

[rifter]

Well, I hate to kick a man while he is down, but

its Latin and means what you were trying to say

should read

it's Latin and means what you were trying to say ... Sorry to give you the double whammy...

Not only that, but his spacebar is broken. It's per se. :P

Re:The only one that matters

[rifter]

Why on earth would you use 3 different filesystems? Hoping to maximize your failure rate?

I like JFS. In the past it didn't get along with NFS very well, but that seems to be fixed for over a year now. But your far better off picking a single FS and sticking with it, except possibly /boot, than doing a different filesystem each partition.

The only people who seem to need to use an unreliable filesystem for /boot are people who insist on using broken boot loaders. Look, in some distros /boot has the kernel in it, and in all of them, it is pretty dan important. Why mess with an unreliable filesystem for any of it?

I use Reiserfs for everything, and like it very much. The performance is decent, but most importantly it has been very reliable through many power outages, which is more than I can say for ext2 and UFS.

compile times

[decoder]

It would be interesting to compare compile times. Compiling is often very slow. Since CPU usage is very high while compiling, having a filesystem that uses low CPU usage could have shorter compile times over one that uses more CPU, because the filesystem would be fighting for CPU time with the compiler. It would be an interesting comparison.

Re:The only one that matters

[Chicks_Hate_Me]

Exactly! maharg should RTFC (Read The Fscking Comment) before posting RTFA flames. Thanks for providing clarification for these idiots.

Re:human readable ? Reiser vs ext3

[Sivar]

Which version of ReiserFS were you using?
I have used EXT3, ReiserFS (not V4) and XFS and through many power outtages have never had problems with Reiser or EXT3, though Reiser is better for my uses (lots of small files).
As far as XFS, I had a situation similar to Mindriot's above, but not quite as serious. (Still, I reformatted).
Now I use a UPS. :)
You might want to give Reiser another chance sometime if you have a bit of extra time. It is now a fairly mature and stable file system.

Yawn

[Medievalist]

So, as I read it:

You pay for Reiserfs's journalling, more efficient use of disk, and ability to represent more complex structures with CPU time.

You pay for the stability, recoverability and backwards compatibility of ext3 with speed of access.

The corporate-ported filesystems (XFS and JFS, which were developed by IBM and SGI using untold googols of man-hours and investment) have better raw performance figures than the relatively newly created, volunteer-funded filesystems.

And ext2 still works just fine, is very easy to set up, and is reasonably fast due to its' lack of journalling or space optimization.

It's nice to see the commonly accepted viewpoint confirmed with numbers, but none of this seems very suprising. Use the fs that is appropriate to your particular needs and philosophy, they all have their place.

Hans Heiser is an idiot, but...

[Anonymous Coward]

I may consider using his filesystem once it gets stable like ext3 and provides a working fsck, and why not, everything from e2fsprogs. If I want speed I just get a new machine.

Cloning compatibility

[dang-a-pin]

I use Ghost for making server images, and while Reiser might be fine and well, you can only make an image of that in a raw, sector by sector form. Ext2 and Ext3 work very nicely however, and I can keep my Debian installs compressed to fit on 1 CD if I need to. Anyway, it has nothing to do with which is a better file system, but I'd say that the practical matters drive most of my IT decisions, and since Ghost is by far the easiest and least time consuming product of its kind, Ghost's demands drive my Linux setups.

That's General Panic to you!

[V.P.]

n/t

Suitability for Laptops

[Anonymous Coward]

Is there any info about which of the filesystems is best suited for laptops. I am thinking in terms of battery consuption and hard disk usage. You don't normally get power failures or crashes on laptops,
so journalling is not so necessary and the hard disk activity that generates (for journal updates) may be avoided. Is ext2 a good choice then? What are your opinions on the matter?

Is tmfps faster?

[Anonymous Coward]

What?

JFS

[Earlybird]

A year or so ago I clocked JFS, ext3, ReiserFS and XFS with a homemade script. JFS consistently beat out the others, so I settled on JFS.

These new benchmarks, while clearly not of the highest scientific calibre, only confirm something I have suspected for a long time: that JFS is among the fastest Linux file systems out there.

JFS is also the most underrated of the journaling file systems. I tend to cheer for the underdog myself. It's true that there were some serious bugs in earlier versions (I got bit by one myself), and this has clearly contributed to its completely undeserved image as a dusty old legacy abandonware file system. Clearly the lack of promotion on IBM's part is to blame; sometimes, hype is good.

Go, JFS!

Re:human readable ? Reiser vs ext3

[Tony Hoyle]

The first time I tried reiser was early in the 2.4.x cycle and it took 3 days to render the drive unbootable.

That last time (after dozens of people said 'it's better now') was about a month ago - debian didn't even get to the end of the install process before reiser f*cked up. I'm not bothering again. (And each time is with known working hardware that's been 100% reliable on ext3 since, before you ask).

JFS/XFS seem quite good... although the thing I like most about ext3 is it's easy to recover with a boot disk as it's compatible with ext2.

Squid and ReiserFS

[hansreiser]

Are you sure it wasn't installing the HD that helped the speed so much?

We do well at squid. If you use reiserfs you can have fun experimenting with such things as storing everything in one directory, etc. One of the annoyances about linux VFS though is that it giant locks the whole directory, so don't do that if you have more than one CPU.

Re:Squid and ReiserFS

[hansreiser]

Apologies, the line:

"Are you sure it wasn't installing the HD that helped the speed so much?"

was meant to be a quotation not a statement by me....

More colors cary more information

[utoddl]

I made a version of this page that colors all the numbers from green (good) through white (mean) to red (bad) instead of just the outlyers. If you're interested, check out my version of the bonnie results.

Re:Cheaters interested in MS FS's?

[im a fucking coward]

On a server, you're never going to USE the GUI, so it's presense in the kernel only reduces stability in the event that Administrator on the console or the remote RDP session fucks something up.

I'm gonna agree to disagree with you here because there were so many things wrong with the 4.0 server line that we had to create elaborate hacks to circumvent several severe, yet subtle design flaws. That many of these errors would later be found to have a have an unexceptable level of criticalality was directly related to the fact that most of the services were built on inhereted functionality stemming from the GUI libs. Why re-invent the wheel, right? In this case that cliche turns out to be wrong, but by the time DEV was coming to this realization, 2k was already in the can and being patched. As I said, the root causes were neither obvious nor trivial. And now you've invested in millions of lines of code. So how do you fix it?

... now I hear this rumor that Longhorn's moving the GUI back out of the kernel. Any truth to that?

As a hypotheticaly blind fool stabbing in the abyss, let me take a guess...BINGO! Give that man a Cupie Doll! Of course, bringing it off is dam near impossible because of the existing infrastructure. Longhorn will continue to be one very long haul.

'Just my ignorant opinion. Don't be suprised if they release MS certified CLI server next week. (^;

Re:Cheaters interested in MS FS's?

[Foolhardy]

Reduced robustness? Before NT4, the GUI was run in CSRSS.EXE. If CSR died, the kernel would die too. Even in modern versions of NT, where CSR still handles a few console things, CSR's death will take down the whole system. From microsoft.com:

Stop 0xC000021A or STATUS_SYSTEM_PROCESS_TERMINATED This Stop message occurs when a user-mode subsystem, such as Winlogon or the Client Server Runtime Subsystem (CSRSS), is fatally compromised and security can no longer be guaranteed. The operating system switches into kernel-mode and generates this error. Because Windows 2000 cannot run without Winlogon or CSRSS, this is one of the few situations where the failure of a user-mode service can bring down the system. Running the kernel debugger is not useful in this situation because the actual error occurred in a user-mode process.

XFS vs JFS for GIS

[Nick Driver]

I thought long and hard about using XFS instead, and even googled for whatever filesystem performance benchmarks I could find on the web back then, and read a few poor measurements discovered on read for XFS under certain circumstances, but nothing really bad stood out in the reported benchmarks across the board about JFS. I just wanted a good reliable and fast journalled filesystem that supported ACL's thru Samba so that my GIS users would be able to set ACL permissions from their Windows clients. I also didn't fully know all the ranges of file sizes that were going to be thrown at this machine with the GIS mapping data files that were not yet available at the time I built the machine, but have since been added. Since the client software (ESRI) expects Windows filesharing only, Samba is the protocol we have to use... until the day comes that we move all that ESRI stuff to inside an Oracle database instead of shared data files. JFS was probably the best choice I could make at the time, and it's proven to perform quite well. The users are pleased and that's what matters most.

Re:human readable ? Reiser vs ext3

[shellbeach]

Same experience here - been using ReiserFS on both my / and /home partitions for over two years, with several power failures and crashes ... and ReiserFS has never even blinked. No problems at all.

I don't know...

[Anonymous Coward]

I don't know what value has a testimonial of a sole home user...

That notwithstanding, my Mandrake 9.1 uses a Reiserfs root partition (just defaults from the distro, no tuning).

It's never, ever, given me any problem. I use it everyday after work hours and all-day-long at weekends. I had to confirm it's really Reiserfs, because I simply don't look at it.

I know of one guy (a distro maker, no less) who recommends Reiserfs over ext3, regarding stability. But I use ext3 at work and it looks as solid as Reiserfs...

Thanks, Hans, and all the people who work with you for a well done job.

PS: When I'm not using my 3D graphics card, what about using the video memory for an extra caching? (Just kidding!)

badly mis-configured web server?

[Anonymous Coward]

I tried reading http://fsbench.netnation.com/ with Links, but it just shows up as garbage; same with old Netscape. What's up with this?

Re:Cheaters interested in MS FS's?

[ckaminski]

Before NT4, if the GUI crashed, the server and network layer would keep chugging. I used to run overnight qualifications on a very large CAD package (that seems to be the only high-end competition left for CATIA :-> ) In the NT 3.1 and particularly the 3.5 days, our regression tests would DESTROY the graphics subsystem, yet when we came in the next day, we could still run our over-the-network data retrievals to get our results before going around to reboot the whole lab.

Today, you'll get the STOP error for nearly anything. It wasn't always that way.

Microsoft made the move to put the GUI in kernel space before the whole video accelerator market got through it's teething phase. By the time the first 3dfx cards hit the market, it was a little late to undo the mass of work done in NT 4.

No one really wants a fair test

[Anonymous Coward]

Yeah, lots of people would like a non-biased test under real-world conditions/configurations. Lots of talk, but no action. With five competitors, non-biased tests will likely leave four losers. Which of the five is willing to take the 80% chance of being one of the losers?

Well, if anyone is willing to fund this, I have the background to do this on both MS and Linux, and could care less which wins. I can also arrange this testing in China, where hardware is only slightly cheaper, but labor costs would be a big winner. Will donate the hardware to a school or your favorite charity when done.

Post here if interested and Ill contact you.

Re:No one really wants a fair test

[Anonymous Coward]

Hmmm...One more idea. Ill publish and get comments on a test plan from /. readers before starting to ensure it's the fair test everyone is looking for.

Comparison to WIndows?

[plinius]

We all know Linux is pretty fast. Now let's have some useful data like comparing to Windows.

Where's the stability test?

[Quince alPillan]

Where's the stability test?

One of my major gripes with ext2 and ext3 is that if for some reason the computer is turned off without unmounting properly (such as...power goes out and you don't have a power backup, you THOUGHT it was shut down but in reality it had one more to go, you bump into the power button accidently, etc) SOMETHING goes wrong.

Last time I was running Mandrake 9.2 on ext3 and I accidently bumped into the power button I lost half the gui because it crashed every time it tried to open.

I may just be unlucky, but this seems to happen every single time the computer isn't shut down properly with one of those file systems. When I can, I use NTFS because then I don't have to worry as much about reinstalling something because it got corrupted when it wasn't shut down right.

Re:Cheaters interested in MS FS's?

[Foolhardy]

It sounds like you have more expierence than me; I just assumed that NT had always crahsed from CSR's death.

I think the main reason to move the GUI into kernel space was to reduce the cross-process overhead. Why they didn't move everything into win32k.sys is beyond me.

...I wonder if CSR's critical status has anything to do with the 'RtlSetProcessIsCritial' function it depends on.

BENCHMARKING IS TEH DEVIL!!

[Anonymous Coward]

Just look at the second table! See the upside down cross?! Bobby Bouchet, FILE SYSTEMS ARE THE DEVIL!

Re:The only one that matters

[Wolfrider]

--Oooh, you play with fire man! You shouldn't be assigning ports 1025 unless root. Usually I pick a higher-numbered set and use it all the time, like 32110. For ssh forwarding news and mail, I use 32110 and 32119.

Re:The only one that matters

[kasperd]

Oooh, you play with fire man! You shouldn't be assigning ports 1025 unless root.

What are you trying to tell me? Of course I do my backup as root. And I must ensure nobody else starts listening on the port, thus it must be less than 1024. I know which protocols are being used on my computers, and 200 is not even assigned in /etc/protocols.