Slashdot Mirror
Btrfs Is Not Yet the Performance King
Ashmash writes "Benchmarks of the Btrfs filesystem have been published by Phoronix that compare it to the XFS, EXT3, and EXT4 file-systems. In the end they conclude that this next-generation Linux filesystem is not yet the performance king. In a great number of the tests, the EXT4 filesystem that was designed to be an interim step to Btrfs actually performs much better than the unstable Btrfs, albeit Btrfs still has more advanced features. Fedora 11 even took longer to boot when using Btrfs than EXT3 or EXT4."
Where's the "-1, tired and worn out" mod option?
I don't care which filesystem is fastest. Kcryptd is the bottleneck on my system, so it really doesn't matter how fast the filessytem is. I want to know which filesystem is the most robust. What filesystem is least likely to lose data?
Give me Classic Slashdot or give me death!
What is newsworthy in the fact that a less tested and less stable filesystem is slower than filesystems that are more mature, stable and well-tested?
Btrfs is mainly created for the Oracle client that doesn't want to use "raw device". It's to improve performance reading/writing large files with high concurrency. So it have to be fast on concurrent request.
What should be looked is :
how mysql perform on BTRFS
how postgres perform on BTRFS
how firebird perform on BTRFS
As there is no magical solution, btrfs is no exception. It's not a general usage FS as is ext (imho). On the desktop, xfs will be the way to go. Performance-wise it's obviously not so great (I do realise that it's still in development and this might change in the future), and the features it delivers are not very interesting as well imho, except maybe for the online defragmentation thingy. But I'm not an enterprise user whis is what this fs aims at I assume.
Still I appreciate the work. Let's hope it doesn't get axed now that Oracle owns Sun and thus already has ZFS.
cheers
=Smidge=
Is it just my observation, or is eldavojohn an idiot?
With Btrfs still being unstable and slow, what is going to happen to it once Oracle completes it's purchase of Sun and gets ZFS and Solaris?
Dual Opteron < $600
I didn't see any indication of the actual filesystem configuration in each case.
Are the defaults for the two filesystems even equivalent? The test isn't really fair if one of them is providing more ordering guarantees than the other.
not sure why phoronix decided to include several test cases which are clearly bottlenecked by something other than the filesystem. Obviously, all 4 filesystems are gonna score the same.
with linus ranting against ext4 i expected to find 'ordered' (mount option to make ext4 acceptable) in the f****** article at least once, but didn't.
so, please guys: do yourself a favour and do the benchmark again! benchmarking ram against platters ain't fair!
I didn't RTFA but why no mention of ZFS?
This space left intentionally blank.
"But her face"
As in, she's so hot...but her face.
Now all of my apps are killer apps!
But does it matter? You know everything's better with butter.
I host some good-sized databases. (aroung 100 GB when dumped as sql statements) I do this on commodity x64 systems and RHEL/EXT3. Although an F/S swap may boost performance some, I'd almost a guarantee in blood before I'd consider swapping.
Performance is already good/excellent, so the benefit would be minor, while the cost of any corruption would be extreme. I'd be far more likely to upgrade the ECC RAM than do anything to the F/S until a few years of stability have assured me that the change would work out.
Given how fast CHEAP hardware is nowadays, speed takes a distant back seat to reliability nowadays!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
What's the advantage of XFS over ext3?
*sigh* back to work...
> What's the advantage of XFS over ext3?
Well I can only speak for my own experience, and obviously yours may be different. But I've had better luck with XFS stability as well as handling of multi-gigabyte files and directories that contain many files. I was soured early on based on some bad experiences with both ext2 and ext3, went to XFS, and haven't had a problem since.
For me deleting very large files is almost instantaneous on XFS, but drags on and on using ext3. I like XFS on my media server box but also use it on a desktop machine. It's also hugely scalable.
Extents and delayed allocation are the big ones, both of which are available in ext4, reiser4, and btrfs.
Unfortunately, xfs is more likely to eat data in individual files than ext3 or ext4 w/ data=ordered. It's apparently less likely to end up with an uncorrectable superblock.
xfs is also horrifically slow for random access of smaller files. If your application calls for massive files, such as databases or a porn library, xfs is preferable over reiserfs or ext3, comparable to ext4, but for general use you're better off with ext3/4 or reiserfs. (by reiserfs I mean 3.6, not reiser4. I can't speak for reiser4)
It's important to remember that there is no one fs to rule them all. Any time anyone tells you "*fs is the best filesystem" they're suffering from fanboyism. xfs is probably not the ideal filesystem for / on a desktop system, but it's a great filesystem for a partition on a server running a database or a fileserver serving large files, or for a DVR application like mythtv.
You want to see EXT3 choke and gobble tons of CPU?
Try creating a bunch of 8-20GB files then unlink (rm) the files.
You'll be amazed to see unlink() on EXT3 use 100% CPU usage for 8-20 seconds PER FILE with all of the other processes starved while EXT3 bogs. Any live data collection in other processes will be stalled until unlink() finishes.
XFS, without a real-time volume, does a fine job of large file deletion without bogging the CPU or starving the live data collection processes.
It's too bad Phoronix didn't bother with benchmarking that scenario.
XFS has a number of features that ext3 is missing. For example, one can easily defragment a mounted XFS filesystem. It's also much more resistant to fragmentation due to the late allocation strategy. xfsdump allows one to easily back up the filesystem and all of the metadata, including incremental backup support. I've used this to replicate an xfs filesystem via netcat when migrating to a new server.
A mounted XFS volume can also be increased on the fly.
XFS is able to scale to much larger partition sizes than ext2/3 (which maxes out at around 8TB with 4K blocks). fsck runs much faster as well. I go and take a coffee break when ext3 decides its time to run its periodic fsck run. ext3 also supports a maximum file size of 2TB and has a limit of around 32K subdirectories per directory. XFS does not have these limitations.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
That's what bags are for
Deleting directory trees is horribly slow in XFS. Try untarring the Linux kernel source to an XFS volume, then delete it. Depending on the XFS options, deletion could take longer than untarring. Way faster in Reiserfs (version 3). I had to move away from XFS for that reason. I use reiserfs. A pity that Reiser4 looks to be dead in the water, but I suppose btrfs means to incorporate or supersede much of Reiser4's advances, and more.
ext3 is slower at almost every operation. FAT is one of the few that is worse than ext2/3 across the board, that is, both slower and less reliable. ext3's slowness is partly because ext3 is ext2 with journaling bolted on. Better to use a file system designed from the start for journaling. ext2 isn't great either. No fun being forced to wait 10 minutes for a file system check because the fs has been mounted too many times without a check, or improperly shutdown. And just because fsck gives you the all clear after repairing things from an improper shutdown doesn't mean everything is fine again, you've got to do a proper shutdown.
To sum up, any modern journaling fs > ext3 > FAT.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
XFS can be tuned for greater performance with options at creation time and mount time. I loved Reiser3's performance but there are too many missing features. I switched to XFS about 2 years ago and haven't looked back since. Small files are still slower to delete but after tuning the system it isn't really that bad at all.
Time makes more converts than reason
Deleting directory trees is horribly slow in XFS.
Yup, one machine I often use is maintained by someone else, and they switched to xfs (from ext3) when rebuilding the system after a big hardware-loss incident. From my perspective, the experience is clearly worse. In particular the whole "deleting lots of little files" thing (which I seem to do quite often) -- in ext3 I never noticed any delay, but xfs seems to take forever to do the same operation.
I get the impression that xfs was designed with a particual usage in mind -- big media servers, IIRC -- and shines there, but is maybe not the best choice for a general-purpose machine.
We live, as we dream -- alone....
All these results just make me wonder why we arn't all using 'xfs' by default nowadays?
http://notanumber.net/
In Soviet Russia?
How can one say that Btrfs is slower when they only tested on a single configuration.
I wouldn't be surprised if Btrfs would outperform the others on systems with multiple disks, especially if it has some ZFS style capabilities.
Also, I didn't see anywhere that they were running a 64bit install... I would hope that the devs for Btrfs are optimizing for 64bit systems.
Reguardless, a single configuration test does not qualify them to say that one filesystem is faster than another... unless they qualify it by saying that "on the only system we benchmarked, btrfs not the performance king." A much less meaningful comment.
Sometimes the best solution is to stop wasting time looking for an easy solution.
Hardly. ZFS and btrfs use a copy on write design that is decidely non-optimal for database usage. Both work best when files are completely rewritten or only appended to. Partial writes to files cause them to get fragmented. This problem is severe enough that btrfs at least is planning special options so that the performance of large databases doesn't go downhill. How they plan on integrating that with a copy on write design is an interesting question.