4348295
story
Comments: 117 +- Hardware: Btrfs Is Not Yet the Performance King on Thursday April 30 2009, @01:40PM
background: url(//a.fsdn.com/sd/topics/topicstorage.gif); width:48px; height:51px;
storage
background: url(//a.fsdn.com/sd/topics/topicsoftware.gif); width:65px; height:65px;
software
background: url(//a.fsdn.com/sd/topics/topiclinux.gif); width:60px; height:70px;
linux
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."
Related Stories
Linux: Ext4 Advances As Interim Step To Btrfs 510 comments
Submission: Btrfs Is Not Yet The Performance King by Anonymous Coward
To be sure of hitting the target, shoot first and, whatever you hit,
call it the target.
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.
Stability, reliability (Score:5, Insightful)
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?
Re:Stability, reliability (Score:5, Informative)
btrfs has several features that help prevent data loss, and in particular silent corruption of data on the disk. It is also handy to be able to take snapshots for backup purposes.
Ext3 and Ext4 are faster because they omit some of these features. There was recently some heated debate about ext4 and data loss, see the Slashdot discussion [slashdot.org] for more links.
With file systems, speed and data integrity are trade-offs.
Parent
Re: (Score:2, Insightful)
With file systems, speed and data integrity are trade-offs.
Not at all. ZFS is a perfect example. Not only is it faster than any Linux file system, but also far more flexible, reliable and far far less likely to lose your data.
Re:Stability, reliability (Score:4, Informative)
Parent
Re:Stability, reliability (Score:4, Insightful)
Parent
Re:Stability, reliability (Score:5, Insightful)
You're right, Sun had no idea their new license would be incompatible with Linux because they wanted to be compatible instead of doing the slimy thing and trying to make it be a selling point over using Linux, which everyone was doing. Alas. for them RMS and Linus travelled back in time and created/used the GPL just to thwart poor Sun.
Parent
Re: (Score:2)
Or, put another way, Sun released ZFS code under an open-source license, and that should be good enough, but the GPL is too focused on rigid adherence to a strict set of rules, and is thus incompatible with many open-source licenses, including Sun's.
How is it that FreeBSD, for example, got Dtrace support included, but Linux can't? Oh, that's right, it's Sun's fault somehow.
Re: (Score:2)
I guess that explains why no non-gpl stuff is on my Debian install.
Oh wait...
Re: (Score:3, Informative)
And what happens? Someone takes the features they need from a non-GPL program/filesystem/etc and creates a GPL version. Yea, great going there with using an incompatible license. Feel free to use a license incompatible with the GPL. Also feel free to whine when someone replaces the functionality of whatever you've written with a GPL version, which is then included in Linux distros or the kernel where huge amounts of users get access to it.
How many years has it been since ZFS has been released and we still don't have a workable linux alternative.
I don't think anyone is whining at Sun.
Re: (Score:3, Informative)
Yes, ZFS is a perfect example of a design that's perfect by its own definition of perfect. For (perfect) example, you can perfectly accidentally add an empty USB drive to a pool and you'll be perfectly unable to ever remove that device without doing a perfectly full mirror or backup.
They've been promising to fix this any day now for years. I'll send you $50 when they do. I'll send you another $50 when I can use it on my Linux box.
I think my money's perfectly safe.
Re: (Score:3, Interesting)
I can't figure out the "accidentally" add a USB drive to a local disk pool part. Why would mixing removable with non-removable devices in ANY volume manager ever be a good idea, and why would preventing cases where people "accidentally" do so be a priority? When you plug in a USB disk, does a little dialog ask "Would you like to add this removable disk to a logical volume including fixed disks?" Didn't think so.
I know what feature you're talking about, but this attempt to make it a big deal is pathetic.
Re:Stability, reliability (Score:4, Informative)
Parent
Re: (Score:2)
Re: (Score:2)
You should see how insightful he gets after eating cabbage and beans.
Re: (Score:2)
That's what bags are for
Re: (Score:3, Interesting)
I'm more interested in a truly distributed file system for making better use of my home LAN full of PCs with those over-sized hard drives that could be being used efficiently.
Several file systems have tried to take advantage of distributed storage, RAID-style, but none are very well maintained or stable or feature-rich for day to day use to my knowledge.
Besides, its a distributed backup system.
Interestingly, it would be easier to store all my data in Freenet [freenetproject.org] and have all my PCs form a darknet with each othe
Re: (Score:2)
Interestingly, it would be easier to store all my data in Freenet and have all my PCs form a darknet with each other.
I guess it would be cool to have a darkLAN, but with Freenet, you have to duplicate your data.
It may make more sense to use GlusterFS [gluster.org] or Hadoop [apache.org] for your LAN.
If you want to add crypto, you could store the above data volumes on plain ol EXT(3|4) filesystems inside a TrueCrypt partition.
Re: (Score:2)
If you're on Linux anyway, why would you use proprietary TrueCrypt instead of Linux' built-in dm-crypt? Most installers even do it for you now.
Re: (Score:2)
To solve that problem I moved over centralized storage with diskless clients using iSCSI volumes and booting with PXE. With gigabit it works fine for daily use, it's much simpler to keep track of data and backups and no more wasted disk space in clients.
And, yes, it's very stable.
Re: (Score:2)
Hm.... As in, "take all the hard drives out of current machines while preserving their contents someplace, install those drives in a new iSCSI NAS box, build a mondo-RAID out of those disparate hard drives, building zones for each machine's boot volume use, restore the clients' disk images into their individual zones, reconfiguring the clients to PXE boot"?
I'm pretty sure new hardware wasn't in GP's wish list. Hence, the iSCSI NAS box isn't happening. What's your plan B?
I'd be curious if anyone could actual
Re: (Score:2, Insightful)
There is always a trade off between performance, correctness/robustness, and features.
Pick 2, and don't complain when a 99.99999% guarantee of no data loss is dog slow compared to a filesystem that offers minimal protection against (meta) data loss.
Re: (Score:2)
I thought so too, but I have noticed that deleting files on ext4 is faster than on ext3 on my dm-crypted drive.
Re: (Score:2)
Hmmm...
Ext3 looses data, ext4 loses data. ah god I have to stop focusing on tangents.(I know you used the word correctly, I can't help examining the words 'loose' and 'lose' to the nth degree. Ext3 would be the answer.
Re: (Score:2)
Hum, I would disagree. I personally think that IBM's GPFS is the least likely to lose data. Heck it is the *ONLY* file system I have seen that keeps trucking when loosing a disk making it up. Sure the files on that disk are no longer available but all the rest are.
Re: (Score:2)
Numbers for mysql performance on BTRFS? (Score:3, Insightful)
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=
Re: (Score:2)
Are you sure you are not talking about ocfs2? ocfs2 was designed to run Oracle clusters.
btrfs's stated goal is to eventually replace ext2/3/4.
Re: (Score:2)
Wrong OCFS was a cluster filesystem that did just enough to run Oracle DB clusters. OCFS2 aims to be a fully fledged cluster filesystem with full Posix schematics.
Re: (Score:2)
You are correct, I should have left off the '2'
Re: (Score:2)
Btrfs is mainly created for the Oracle client that doesn't want to use "raw device". ...It's not a general usage FS as is ext (imho). On the desktop, xfs will be the way to go.
I'm curious where you're getting this from. It's true that btrfs was originally started for Oracle, but the discussions on the kernel mailing list clearly show that btrfs is intended to be a general purpose filesystem. Ted Ts'o (one of the main ext4 guys) has spoken about btrfs eventually superceding ext4.
Re: (Score:2)
Yeah but as always Ted Ts'o has made statements about whats going to happen, before there is any data in there to support these statements.
*if your about to mod me troll/flamebait you clearly don't get it
Re: (Score:2)
Why recommend xfs, when jfs is smaller and faster?
Re: (Score:2)
Because XFS seems to get more attention from developers. JFS seems to be almost abandonware. For example the DMAPI stuff no longer works, and even IBM don't support that feature of the FS anymore.
Also you can turn XFS into a clustered filesystem if you pay the right money to SGI/Rackable. JFS can't do that.
Put the money where it matters... (Score:2)
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
What will happen to Btrfs (Score:3, Informative)
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?
Re: (Score:2, Interesting)
Just a quick note about the recently announced purchase of Sun by Oracle. This does not change Oracle's plans for Btrfs at all, and Btrfs is still a key project for us. Please, keep your btrfs contributions and testing coming.
http://article.gmane.org/gmane.comp.file-systems.btrfs/2880 [gmane.org]
filesystem config for each case? (Score:2)
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.
several useless metrics (Score:3, Insightful)
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.
Re: (Score:3, Insightful)
Because Phoronix does really crappy pointless benchmarks all the time. Occasionally they sucker me into reading them and I always wish I hadn't
ZFS? (Score:2, Insightful)
I didn't RTFA but why no mention of ZFS?
Re: (Score:2, Insightful)
The short version is that ZFS isn't available for linux, and this is a linux FS benchmark on a linux specific site.
You could run the same benchmark on OpenSolaris vs Linux on the same hardware, but this wouldn't be particularly meaningful: different storage stack, vfs, etc. Even if the benchmark convinced someone that ZFS is better, they couldn't switch to it, because again, there is no linux port.
You could benchmark the userspace ZFS on Fuse driver, but this is meaningless because the Fuse ZFS implementati
Re:hmm (Score:4)
Parent
How is this news? (Score:4, Insightful)
Parent
Re: (Score:2)
What's the advantage of XFS over ext3?
Re: (Score:2, Informative)
> 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 b
Re: (Score:2)
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
Re: (Score:2)
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 -- a
Re:format stability (Score:4, Informative)
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.
Parent
Re: (Score:2)
Re: (Score:2)
A mounted XFS volume can also be increased on the fly.
XFS is able to scale to much larger partition siz