login
Search
Grant Miner posted some interesting benchmark results to the lkml, comparing five journaling filesystems available with the current 2.6.0-test2 development kernel. The tests were conducted with a very simple shell script, mainly timing how long it takes to copy, tar, and remove directories, performing several syncs in between. He summarizes:
- ext3's syncs tended to take the longest [at] 10 seconds, except
- JFS took a whopping 38.18s on its final sync
- xfs used more CPU than ext3 but was slower than ext3
- reiser4 had highest throughput and most CPU usage
- jfs had lowest throughput and least CPU usage
Some interesting discussion follows, debating the results and offering further suggestions on making the tests more useful. For example, Andrew Morton [interview] proposed including ext2 in the tests as a baseline, and Hans Reiser noted that reiser4 continues to improve rapidly. Read on for the full test results and much of the following discussion.
From: Grant Miner To: linux-kernel Subject: Filesystem Tests Date: Tue, 05 Aug 2003 21:30:48 -0500 I tested the performace of various filesystems with a mozilla build tree of 295MB, with primarily writing and copying operations. The test system is Linux 2.6.0-test2, 512MB memory, 11531.85MB partition for tests. Sync is run a few times throughout the test (for full script see bottom of this email). I ran mkfs on the partition before every test. Running the tests again tends to produces similar times, about +/- 3 seconds. The first item number is time, in seconds, to complete the test (lower is better). The second number is CPU use percentage (lower is better). reiser4 171.28s, 30%CPU (1.0000x time; 1.0x CPU) reiserfs 302.53s, 16%CPU (1.7663x time; 0.53x CPU) ext3 319.71s, 11%CPU (1.8666x time; 0.36x CPU) xfs 429.79s, 13%CPU (2.5093x time; 0.43x CPU) jfs 470.88s, 6%CPU (2.7492x time 0.20x CPU) What's interesting: * ext3's syncs tended to take the longest 10 seconds, except * JFS took a whopping 38.18s on its final sync * xfs used more CPU than ext3 but was slower than ext3 * reiser4 had highest throughput and most CPU usage * jfs had lowest throughput and least CPU usage * total performance of course depends on how IO or CPU bound your task is Individual test times (first number again is time in seconds, second is CPU usage, last is total again) reiser4 Copying Tree 33.39,34% Sync 1.54,0% recopying tree to mozilla-2 31.09,34% recopying mozilla-2 to mozilla-3 33.15,33% sync 2.89,3% du 2.05,42% rm -rf mozilla 7.41,52% tar c mozilla-2 52.25,25% final sync 6.77,2% 171.28,30% reiserfs Copying Tree 39.55,32% Sync 3.15,1% recopying tree to mozilla-2 75.15,13% recopying mozilla-2 to mozilla-3 77.62,13% sync 3.84,1% du 2.46,21% rm -rf mozilla 5.22,58% tar c mozilla-2 90.83,12% final sync 4.19,3% 302.53,16% extended 3 Copying Tree 39.42,25% Sync 9.05,0% recopying tree to mozilla-2 79.96,9% recopying mozilla-2 to mozilla-3 98.84,7% sync 8.15,0% du 3.31,11% rm -rf mozilla 3.71,39% tar c mozilla-2 74.93,13% final sync 1.67,1% 319.71,11% xfs Copying Tree 43.50,32% Sync 2.08,1% recopying tree to mozilla-2 102.37,12% recopying mozilla-2 to mozilla-3 108.00,12% sync 2.40,2% du 3.73,32% rm -rf mozilla 8.75,56% tar c mozilla-2 157.61,7% final sync 0.95,1% 429.79,13% jfs Copying Tree 48.15,20% Sync 3.05,1% recopying tree to mozilla-2 108.39,5% recopying mozilla-2 to mozilla-3 114.96,5% sync 3.86,0% du 2.42,17% rm -rf mozilla 15.33,7% tar c mozilla-2 135.86,6% final sync 38.18,0% 470.88,6% Here is the benchmark script: #!/bin/sh time='time -f%e,%P ' echo "Copying Tree" $time cp -a /home/test/mozilla /mnt/test echo "Sync" $time sync cd /mnt/test && echo "recopying tree to mozilla-2" $time cp -a mozilla mozilla-2 && echo "recopying mozilla-2 to mozilla-3" $time cp -a mozilla mozilla-2 && echo "sync" $time sync && echo "du" $time du mozilla > /dev/null && echo "rm -rf mozilla" $time rm -rf mozilla echo "tar c mozilla-2" $time tar c mozilla-2 > mozilla.tar echo "final sync" $time sync
From: Peter Chubb Subject: Filesystem Tests Date: Wed, 6 Aug 2003 13:47:40 +1000 >>>>> "Grant" == Grant Miner writes: Grant> I tested the performace of various filesystems with a mozilla Grant> build tree of 295MB, with primarily writing and copying Grant> operations. It'd be interesting to add in some read-only operations (e.g., tar to /dev/null) because, in general, filesystems trade off expensive writes vs expensive reads. Especially as the disk gets fuller. (What I mean is that filesystems that do more work to optimise disk layout will be slower to write, but should be faster to read. And `easy' optimisations for disk layout get harder as the disk gets fuller and fragmented). So the other thing that'd be interesting to test is doing the same thing after having pre-fragmented the disk in some predictable way. -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au You are lost in a maze of BitKeeper repositories, all slightly different.
From: Andrew Morton Subject: Re: Filesystem Tests Date: Tue, 5 Aug 2003 22:41:52 -0700 Grant Miner wrote: > > I tested the performace of various filesystems with a mozilla build tree > of 295MB, with primarily writing and copying operations. The test > system is Linux 2.6.0-test2, 512MB memory, 11531.85MB partition for > tests. Sync is run a few times throughout the test (for full script see > bottom of this email). I ran mkfs on the partition before every test. > Running the tests again tends to produces similar times, about +/- 3 > seconds. > > The first item number is time, in seconds, to complete the test (lower > is better). The second number is CPU use percentage (lower is better). > > reiser4 171.28s, 30%CPU (1.0000x time; 1.0x CPU) > reiserfs 302.53s, 16%CPU (1.7663x time; 0.53x CPU) > ext3 319.71s, 11%CPU (1.8666x time; 0.36x CPU) > xfs 429.79s, 13%CPU (2.5093x time; 0.43x CPU) > jfs 470.88s, 6%CPU (2.7492x time 0.02x CPU) But different filesystems will leave different amounts of dirty, unwritten data in memory at the end of the test. On your machine, up to 200MB of dirty data could be sitting there in memory at the end of the timing interval. You need to decide how to account for that unwritten data in the measurement. Simply ignoring it as you have done is certainly valid, but is only realistic in a couple of scenarios: a) the files are about the be deleted again b) the application which your benchmark simulates is about to spend more than 30 seconds not touching the disk. This discrepancy is especially significant with ext3 which, in ordered data mode, will commit all that data every five seconds. If the test takes more than five seconds then ext3 can appear to take a _lot_ longer. But it is somewhat artificial: that data has to be written out sometime. Solutions to this inaccuracy are to make the test so long-running (ten minutes or more) that the difference is minor, or to include the `sync' in the time measurement. And when benching things, please include ext2. It is the reference filesystem, as it were. It tends to be the fastest, too.
From: Szakacsits Szabolcs Subject: Re: Filesystem Tests Date: Wed, 6 Aug 2003 12:35:42 +0200 (MEST) On Tue, 5 Aug 2003, Andrew Morton wrote: > Solutions to this inaccuracy are to make the test so long-running (ten > minutes or more) that the difference is minor, or to include the `sync' in > the time measurement. And/or reduce RAM at kernel boot, etc. Anyway, I also asked for 'sync' yesterday and Grant included some but not after every each tests. I run the results through some scripts to make it more readable. It indeed has some interesting things ... reiser4 reiserfs ext3 XFS JFS copy 33.39,34% 39.55,32% 39.42,25% 43.50,32% 48.15,20% sync 1.54, 0% 3.15, 1% 9.05, 0% 2.08, 1% 3.05, 1% recopy1 31.09,34% 75.15,13% 79.96, 9% 102.37,12% 108.39, 5% recopy2 33.15,33% 77.62,13% 98.84, 7% 108.00,12% 114.96, 5% sync 2.89, 3% 3.84, 1% 8.15, 0% 2.40, 2% 3.86, 0% du 2.05,42% 2.46,21% 3.31,11% 3.73,32% 2.42,17% delete 7.41,52% 5.22,58% 3.71,39% 8.75,56% 15.33, 7% tar 52.25,25% 90.83,12% 74.93,13% 157.61, 7% 135.86, 6% sync 6.77, 2% 4.19, 3% 1.67, 1% 0.95, 1% 38.18, 0% overall 171.28,30% 302.53,16% 319.71,11% 429.79,13% 470.88, 6% BTW, zsh has a built-in 'time' so measuring a full operation can be easily done as 'sync; time ( my_test; sync )' Szaka
From: Hans Reiser Subject: Re: Filesystem Tests Date: Wed, 06 Aug 2003 18:06:37 +0400 Andrew Morton wrote: >But different filesystems will leave different amounts of dirty, unwritten >data in memory at the end of the test. On your machine, up to 200MB of >dirty data could be sitting there in memory at the end of the timing >interval. You need to decide how to account for that unwritten data in the >measurement. Simply ignoring it as you have done is certainly valid, but >is only realistic in a couple of scenarios: > unless I misunderstand something, he is running sync and not ignoring that. I don't think ext2 is a serious option for servers of the sort that Linux specializes in, which is probably why he didn't measure it. reiser4 cpu consumption is still dropping rapidly as others and I find kruft in the code and remove it. Major kruft remains still. -- Hans
From: Diego Calleja García Subject: Re: Filesystem Tests Date: Wed, 6 Aug 2003 18:34:10 +0200 El Wed, 06 Aug 2003 18:06:37 +0400 Hans Reiser escribió: > I don't think ext2 is a serious option for servers of the sort that > Linux specializes in, which is probably why he didn't measure it. Why? > > reiser4 cpu consumption is still dropping rapidly as others and I find > kruft in the code and remove it. Major kruft remains still. Cool.
From: Mike Fedyk Subject: Re: Filesystem Tests Date: Wed, 6 Aug 2003 11:04:27 -0700 On Wed, Aug 06, 2003 at 06:34:10PM +0200, Diego Calleja Garc?a wrote: > El Wed, 06 Aug 2003 18:06:37 +0400 Hans Reiser escribi?: > > > I don't think ext2 is a serious option for servers of the sort that > > Linux specializes in, which is probably why he didn't measure it. > > Why? Because if you have a power outage, or a crash, you have to run the filesystem check tools on it or risk damaging it further. Journaled filesystems have a much smaller chance of having problems after a crash. From: Diego Calleja García Subject: Re: Filesystem Tests Date: Wed, 6 Aug 2003 20:45:14 +0200 El Wed, 6 Aug 2003 11:04:27 -0700 Mike Fedyk escribió: > > Journaled filesystems have a much smaller chance of having problems after a > crash. I've had (several) filesystem corruption in a desktop system with (several) journaled filesystems on several disks. (They seem pretty stable these days, though) However I've not had any fs corrution in ext2; ext2 it's (from my experience) rock stable. Personally I'd consider twice the really "serious" option for a serious server.
From: Andrew Morton Subject: Re: Filesystem Tests Date: Wed, 6 Aug 2003 14:19:05 -0700 Mike Fedyk wrote: > > On Wed, Aug 06, 2003 at 06:34:10PM +0200, Diego Calleja Garc?a wrote: > > El Wed, 06 Aug 2003 18:06:37 +0400 Hans Reiser escribi?: > > > > > I don't think ext2 is a serious option for servers of the sort that > > > Linux specializes in, which is probably why he didn't measure it. > > > > Why? > > Because if you have a power outage, or a crash, you have to run the > filesystem check tools on it or risk damaging it further. > > Journaled filesystems have a much smaller chance of having problems after a > crash. Journalled filesytems have a runtime cost, and you're paying that all the time. If you're going 200 days between crashes on a disk-intensive box then using a journalling fs to save 30 minutes at reboot time just doesn't stack up: you've lost much, much more time than that across the 200 days. It all depends on what the machine is doing and what your max downtime requirements are.
From: Paul Dickson Subject: Re: Filesystem Tests Date: Wed, 6 Aug 2003 03:48:42 -0700 On Tue, 05 Aug 2003 21:30:48 -0500, Grant Miner wrote: > The first item number is time, in seconds, to complete the test (lower > is better). The second number is CPU use percentage (lower is better). > > reiser4 171.28s, 30%CPU (1.0000x time; 1.0x CPU) > reiserfs 302.53s, 16%CPU (1.7663x time; 0.53x CPU) > ext3 319.71s, 11%CPU (1.8666x time; 0.36x CPU) > xfs 429.79s, 13%CPU (2.5093x time; 0.43x CPU) > jfs 470.88s, 6%CPU (2.7492x time 0.02x CPU) That should be 0.20x CPU for jfs, right? -Paul From: Grant Miner Subject: Re: Filesystem Tests Date: Wed, 06 Aug 2003 06:39:13 -0500 Paul Dickson wrote: > That should be 0.20x CPU for jfs, right? > > -Paul > > yes, that's right.
Standard Tests
I don't want to sound all high and mighty, but... it seems that filesystem benchmarking happens all the time. I mean, benchmarking of the entire linux system is happening to make sure that the latest improvment really is an improvement. But why hasn't a 'standard' test suite been developed? With a set of standard and thoughtfully planned out test for filesystem performace.
That way there wouldn't be questioning of testing methods or 'correctness', and it would be fairly easy for a user at home to perform the same test, if they wanted.
While specific benchmarks need to be created to measure a specific facet of kernel performance, why not have a standard set of benchmarks for something that's fairly standard, like filesystem performance?
rather difficult, I'd think
it would be rather difficult to develop a "standard" test suite for filesystems. They're tuned to specific assumptions and capabilities. Latency, throughput, processor usage, cluster size, fragmentation, journaling - they're all factors. And the file systems named above (excepting ext2) are all very young, rapidly developing, rapidly changing that it doesn't make sense to lock yourself into specific tests yet.
But then again, they're kinda nice just for a vague sense of how things are progressing.
What is a 'standard test'?
I think it's very hard to come up with any 'standard' test. People use their systems differently, for totally different purposes, often with quite different software. Not even might the same filesystem have better or worse real-life results when the software is changed (different mta, db, ...), but the requirements for specific usage might be totally different. You may use it as a desktop, and I could use the filesystem on a fileserver. We will have a different experience... Even if we both use the same software in the same way for the same purpose, you might have more memory or produce bigger files (which both would benefit xfs, for instance). There are so many factors, that the only way to tell which fs would be best for you, on your specific system - kernel, hardware, software, usage - would be if you test all filesystems yourself.
I'm also a bit fed up with people either hyping or cursing filesystems without solid claims to back it up. For instance, half of the people is shouting xfs is a instable bunch of crap that should never have been adapted to the linux kernel and puts all of your data in jeopardy; and the other half screams exactly the opposite, citing it's fast and stable, again without much proof. Who can you trust, if not yourself? Most people can't stay scientifically sound and steer clear of prejudice and partiality; people want to either be a fanboy cheerleader squad (unconditional love) or just loathe the crap out of something (prejudiced hate).
If you want to know something about these things, do it yourself. Don't rely on the opinion of others, unless you know them and understand them so you can judge the value of their claims.
And there is no such thing as a 'standard test'. The rule of averages says that for general use, with the same hardware, there can't be that much difference between those systems anyway (who would otherwise bother to develop a totally retarded slow filesystem). I would be more worried about stability and fragmentation, but, sadly enough, this is almost impossible to test because of individual choices for hardware, software, usage etc. I bet that if I set up a system for you, you could never guess which filesystem it's running. That says enough.
With other words, unless you really really really know what you're doing, choosing the filesystem which name you like most is as good a solution as any. :)
Agreed.
For the typical desktop, and even for many lightly-loaded servers, I have to agree. In fact, I'd go further and say "Just use whatever your distro's default install gives you," because that's likely the configuration that's been the most heavily tested by your vendor. (Maybe go ahead and tweak things slightly if that suits you, but stay within a stone's throw of stock.)
There are several benchmarks out there--dbench, lmbench, various tests within ConTest, etc.--and each of them has strengths and weaknesses.
For servers that care about performance for a specific application or set of applications, one should find a benchmark which provides a similar workload. A mail server with many moderate-sized files, lots of locking/fsync, and huge directories has different needs than a database server with one huge file. Both have different needs than an ftp or streaming media server, which does many parallel reads of large, mostly static files. It is unlikely that any benchmark will produce a single figure of merit that works for such disparate applications.
And that's part of the beauty of filesystem choice. Reiser might be good in the mail-server setting. XFS might be good for streaming. EXT3 might be a good compromise across many domains. (I'm just picking a mapping of applications to filesystems here -- the actual map may be very different than the rhetorical example I give here.) The point is that you can choose, and people are encouraged to pick the filesystem that seems to work best for them.
As for stability? That's why you don't roll things out into production right away, and you keep backups. If one FS craps in setting A, a different one might crap in setting B. No software is immune to bugs. Personally, in using Linux for nearly 11 years now, I've only lost files due to non-fs-related crashes--either power outages, development kernel crash, or just plain taking the system over the edge. (Oh, and I did lose a pile when e2defrag crashed when I resized my xterm. Thank goodness for backups.) I've never experienced filesystem corruption due to the fs' driver itself. (Granted, I haven't experimented with a wide array of fs's either.)
True. Just one note: After I
True. Just one note:
After I tried all of them, i actually can fairly easily tell what filesystem a box is using.
They all make the disk produce different sounds.
:-D
But indeed.
lots of small files
With Mozilla source tree, it's a lot of small files - and this was always something, Raiser excelled in. What about adding some different tests? for example to run some complex queries (combined selects/inserts/deletes/updates) on a large database (> 1GB, clean boot, small buffers etc. of course)?
For me, this would be MUCH MORE interesting information.
how about...
...you run that test then? ;)
Uh Ohh...
Jeremy, welcome the new server to its first Slashdotting. :-)
/.'ed
but it's only in the developers section of slashdot, so it's not like you've got a full /.'ing happening.
Ahh yes...
Didn't catch that. Thanks
Filesystem Tests
Shouldn't the test also be runned on a disk with various amount of empty space? Reiser4, and probably other journalled filesystems, gets slower when the disk runs out of empty space. For a home user with a limited budget, it's a big thing if you can't use maybe 5% of your diskspace because the FS becomes too slow.
maybe...
...you should run that test!
XFS
FWIW, it may have used more CPU but I've migrated my machines to XFS and have been very happy with the performance and stability of the filesystem.
It really performs well with lots of memory and large file systems. It also is very good about saving disk space with lots of small directories. (Reiser4 does this as well).
Linux really has some of the most amazing filesystems.
Notice very short SYNC times on XFS
That's because it is a real journaling filesystem. Sorry to break it to you all. Try ripping out the disks during your script and then seeing which one really need not fsck. I'll put money on JFS and XFS. XFS is the best filesystem available for Linux - and that's too bad people got behind ext3 because it is convenient. Some will say that XFS is hacked into Linux from IRIX - good! Any commercial discipline rubbing off into the Linux kernel is a good thing. Ever hear about those strange bugs involving laptops and EXT3 corruption?
I'm also upset that RedHat still refuses to make it easy to get XFS running on out of the box installs.
I'll continue to use FreeBSD wherever possible until committing to and the using of Linux becomes more of a meritocracy than a popularity contest/Mobocracy penguin logos and think geek shirts with penguins and Slashdot fan-boys.
"fan-boy" responds
Ah, but I lost a couple of filesystems using XFS. Switching back to ext3 on the same machine solved all corruption problems and the machine is still running today. It crashed three times in production as soon as XFS got a little load. Two times it was completly impossible to recover the filesystem with the xfs tools and I had to restore from backup. That turned a two minute reboot process which most people wouldn't notice into a two hour restore process which everybody noticed.
I used to admin Irix systems and I loved them (though I disagree with the commercial "discipline"). And I used to be a big fan of XFS but I think they have some problems to solve before I'll try it in production again.
In short, my using ext3 isn't because it's convenient, it's because it's both a journaled filesystem and it has the heritage of the stable ext2 code. XFS will run fine under desktop or light loads, but for server's I'd suggest treading carefully.
XFS Stability
XFS on Linux kernel 2.4 has been pretty stable, with the CVS tree consistently having bug fixes, split patches being made available with regular human-defined snapshots for those who don't want to use the CVS tree, and with work for the 1.3 release progressing acceptably.
Your comments about the stability of XFS in your experience is not very reassuring. Were you able to report these problems to the XFS mailing list? Would it be possible for you to share which XFS version (eg: CVS or split patch snapshot date or release number) and Linux kernel version you were using, and what specific problems you ran into that went away when you migrated to ext3?
--> Jijo
Everything I have ever done in filesystems suggests
Everything I have ever done empirically suggests this is more of the FUD surrounding those who "love" to hate Microsoft (with Linux) vs. those who like Unix. You are sounding like a RedHat fan-boy.
I have purposefully brutalized several XFS partitions and ripped disks out during various operations, ranging from reading, writing, databases running, caches being ripped out from underneath themselves. Then again, I tend to use higher end equipment, so the IDE based Celeron box might have some trouble?
One of the many glaring mistakes the maintainers (Marcelo and Linus) have made is keeping XFS out of 2.4 officially. That would force them to fix the broken vfs.
Oh well. I guess linux will have to wait for 2.6 to have a real native filesystem. And I'm not talking about that concoction Hans the whiner made.
I have a bad experience
I have a similar experience, I use SGI and I want to give a chance to xfs on linux, but I lost my work (small home development, but I like it) because I wasn't able to recover that xfs partition from a Hasechoft XP atack (I have another one with raiserfs, no problem). I have return to raiserfs, I have been using it in servers for 3 years without problems.
Not (at least) in 2.4.20 and 2.4.21 XFS
We're running a samba server with raid 1 volumes and XFS in a production environment for 8 months, and (fortunately, I'll knock on wood) we've never suffered any corruption in any of the 5 shares we got.
Note: the bottleneck is in the network: the machine is an old pII 333/384MB of ram and 2 Realtek NIC/100Mbps adapters. the performance is really good, though sometimes is really busy :)
We all have bad stories
Hi,
The problem with such statements is that you will always find someone that is happy with this or that.
I use ext3 for the convenience of the migration but I recently had a problem where the fs was completely corrupted.
The bottom line, nothing is perfect and there is probably a scenario where each option will be th BEST.
Recovery Time vs Runtime Overhead
Andrew Morton wrote:
> Journalled filesytems have a runtime cost, and you're paying that all > the
> time.
>
> If you're going 200 days between crashes on a disk-intensive box then > using
> a journalling fs to save 30 minutes at reboot time just doesn't stack > up:
> you've lost much, much more time than that across the 200 days.
>
> It all depends on what the machine is doing and what your max
> downtime
> requirements are.
Working in a commercial environment, I find most end-users and management would rather have the server back up in a shorter time than worry about a few % of overhead associated with journalling. In addition, data loss is an important sticking point with them, and ext3's ability to journal data, not just meta-data, minimizes that threat. On my workstation I am using ReiserFS to get familiar with it; on my servers I want ext3...
In general, however, I believe it's up the the SysAdmin and application owner to work to gether to understand an application's data integrity requirements and disk I/O behavior, as these will provide insight into what filesystem(s) is/are most appropriate. No benchmark will ever provide a one-size-fits-all answer, no matter how well designed.
Rick
failover, clusters, etc
If you have failover boxes or are operating with clusters, etc. then a quick boot isn't such a pressing requirement. In some tests for example, ext2 is more than twice as fast as ext3. Now when the costs of reboot time are weighed into the equation, this might mean you can get away with 30 machines in your cluster instead of 50.
As you said, its obviously dependant on requirements.
in a lab setting journalling is crucial
in a computer lab setting, you need journalling. Users get tired of waiting for the fsck to finish and hit the reset key...
Don't confuse the lab machines w/ the lab server
The lab server can more easily use a non-journalling FS. Fast boot times on machines in the lab, though, is a must. Personally, I'd suggest that each of the lab computers only have the following on their HD anyway:
Put everything else on file servers elsewhere. That way, students' data follows them everywhere, and you spend minimal time fixing software on each machine. That fileserver can fsck all it wants, and your students can mash on Reset all they want, and it should all still work pretty well.
please ADD EXT2 to the benchmark
could you put a EXT2 test, just for comparison??
thanks
> reiser4 had highest through
> reiser4 had highest throughput and most CPU usage
CPU usage means nothing if expressed as %. What means is absolute
amount of CPU time consumed to run the test.
> I don't think ext2 is a serious option for servers of the sort that
> Linux specializes in, which is probably why he didn't measure it.
I bet you're kidding.
I run several servers including 500 GB RAID 5 tours, and they all run ext2.
The box are using software RAID, have an UPS, selected hardware in
order to avoid student level drivers, so never reboot.
Hans, I know your valid assertion that in case of a crash, in EXT2
nothing is granting that e2fsck will be abble to recover properly.
Now, since properly installed servers truely never crash nowdays,
then it means nothing anymore, neither means the time needed to
run e2fsck.
The true issues that will make me switch to Reiserfs 4 at some point
are:
1. I net behond 1 GB, EXT2 might not be suited due to it's 32 bits
nature
2. Reiserfs 4 has transaction.
The last point is by far the most important since it enables to
easily build an application that will never leave datas in a poor
state as a matter of coherency in case of an application level
crash.
Operating system crashes are a thing of the past if you carrefully
install your Linux box (many thanks to Linux developpers),
disks failures are mainly a thing of the past if using software RAID
0.9 or higher which is something absolutely strong,
so, if an application can be written so that an application crash
will not corrupt overall datas consistency, then it's a step futher
to true reliability because application level crash will never be a
thing of the past, as opposed to operating system level crash,
because it means to much engeneering power per feature, so too slow
evolution of available services, and it's possible to achieve only
for resonably simple operations.
On the other side, journaling was the wrong way to not solve the
problem, so should not be seen as a major improvement, just a way
to minimise the impact of a poor system.
The real question should be: why install a poor system nowdays since
truely good ones are possible.
The fact that most distributions will install EXT3 or Reiserfs 3
just means that uncompetent users and system administrator is still
the majority, and that marketing is still targetting these.
Hubert Tonneau
Windows Comparison...
They should compare the benchmarks with Windows, and there upcoming next generation file system too, once its available. That would be a good baseline to compare against.
ext2
1. I net behond 1 GB, EXT2 might not be suited due to it's 32 bits
nature
Please don't talk about things you don't have idea of.
From
XFS is fast but is it reliable?
I ran some bonnie++ benchmarks with 16GB size on a 2.4 kernel (iirc 2.4.20-xfs) and XFS won hands down. It used roughly 1/3 the cpu of ext3 and 1/2 the cpu of reiserfs to write the same amount of data per second.
However, yesterday while I was running 2.6.0-test1-bk2 I ran xfs_fsr to defrag the drive... supposedly this is safe to do. However, XFS decided to corrupt itself in a very strange way. I can still read all the files when booted on knoppix with 2.4.20-xfs but knoppix 2.4.21-xfs and the kernels I had compiled myself for the distro I am running on the box see many files that are null filled. The exact same files on the same drive/fs under 2.4.20-xfs still see all the files. So I think I have decided to convert back to ext3 until something faster that is stable comes along. :<
XFS devel - I will open a bugzilla bug wrt this issue once my main system is back online.
reliable?
i use xfs in my box for almost a year now..i had reiserfs at the time and someday..the power went down and the linux partition simply corrupted...couldnt even mount it...i asked for help and this was +- less what i got: who told ya to use reiserfs? so i changed to xfs and never had a problem since..some ppl called me crazy at the time cose they said it was unstable...and even my distro (gentoo) didnt had a xfs kernel....the facts?!?!? ext2 sux, ext3 = stable, reiserfs dont really know hows it goin now, and i dont really wanna know ;]
want a really good FS that stands crashes, power failures and even BLACKOUTS!! hahahaha ;) ????
XFS til death ;)
CPU Usage
The new FS isn't efficient yet, but I'd still expect the cpu usage to be higher when it completes the task 131.25 seconds faster...
Filesystems test
I think that Raiser4 utilize 30% of CPU because make in 171s the same job that ext3 make on 302s with 16%.
If You consider 302*16/171=28 I think that Raiser make a good job.
The overhaed is only 2s!!
Do You think so??
Sorry for my english!!
andrea.diodato@farma3.it
The tests
For different tasks, different things are important. Copyng/deleting/ files is important for usual users, while for the database administrators it will be interesting to see how these filesystems perform in a heavy loaded database server:
- What is its impact on the overall performance (thousands tests of execution of typical DB tasks (insert/delete/update). I mean DBMS response time,throughput (clients per second). Of course the results will further depend on the DBMS used, so several DBMS has to be benched.
I think that this will yield a real world results. Other task can be linux kernel compiling from a clean state - there is combination of I/O and CPU load...