Forgot your password?
typodupeerror
Data Storage Software Linux

Btrfs Is Not Yet the Performance King 117

Posted by timothy
from the happy-churning dept.
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."
This discussion has been archived. No new comments can be posted.

Btrfs Is Not Yet the Performance King

Comments Filter:
  • by Hatta (162192) on Thursday April 30, 2009 @02:47PM (#27776767) Journal

    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?

    • by Cassini2 (956052) on Thursday April 30, 2009 @02:52PM (#27776853)

      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.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        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.

        • by TooMuchToDo (882796) on Thursday April 30, 2009 @03:47PM (#27777641)
          Unfortunately, Sun had no plans on licensing ZFS so it could run on Linux. Will Oracle change it's mind? Probably not, hence the reason btrfs is reproducing features of ZFS.
          • by onefriedrice (1171917) on Thursday April 30, 2009 @03:56PM (#27777761)
            I think it's important to keep in mind that it is the GPL that is incompatible with other free licenses, not the other way around.
            • Re: (Score:1, Troll)

              by TooMuchToDo (882796)
              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.
              • 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.

            • by Nevyn (5505) * on Thursday April 30, 2009 @04:53PM (#27778699) Homepage Journal

              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.

              • Slimy thing? It's business. Fucking FSF hippies.

                • by ultrabot (200914)

                  Slimy thing? It's business. Fucking FSF hippies.

                  That's not what Sun has been telling us (instead they have been citing technical/legal reasons).

                  • I wish I could cite where I saw this, but I remember reading an article stating that the CDDL was intentionally designed to be GPL incompatible; they didn't want the Linux crowd mooching off their work.

                    • by ultrabot (200914)

                      I wish I could cite where I saw this, but I remember reading an article stating that the CDDL was intentionally designed to be GPL incompatible; they didn't want the Linux crowd mooching off their work.

                      You probably saw it all over the place - that's the "common wisdom" among everybody but Sun and Sun fanboys.

              • by Sentry21 (8183)

                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.

                • Sun could have dual licenced ZFS under GPL and BSD. Why didn't they?
                  • by chrish (4714)

                    Why would they? Seems to me like releasing it at all was a huge step for a business; they could've sat on it and kept it to their storage systems as a competitive advantage.

                    Releasing it under two different licenses just to appease FSF fanatics at least doubles the effort required to review the code and get it released. It probably gives their lawyers high blood pressure, too.

                    I just can't see how this is Sun's problem and not Linux's problem. Why isn't the kernel flexible enough to allow loading filesyste

                    • by mhall119 (1035984)

                      I just can't see how this is Sun's problem and not Linux's problem. Why isn't the kernel flexible enough to allow loading filesystems without being merged into the kernel (or is it? I honestly don't know)?

                      You can fun a file system in userspace, it's just quite a bit slower that way. I believe you can run ZFS on Linux with Fuse.

                      For what it's worth, you can legally run ZFS as a kernel module without violating either license, you just can't distribute it that way because the GPL would require that the ZFS code be distributed under a compatible license.

                    • releasing it under the GPL would do more than appease FSF "fanatics", it would allow ZFS to be redistributed with the linux kernel. kind of a useful thing to do, don't you think?
            • I guess that explains why no non-gpl stuff is on my Debian install.

              Oh wait...

          • by chrish (4714)

            It's so very nice actually using ZFS (on my FreeBSD server) instead of waiting around for the Linux guys to reinvent the wheel with BTRFS.

            Dynamically adding storage to your filesystems is a killer feature, although ZFS certainly likes to have a lot of memory handy. I've actually held off on adding a few things to the server (Squid proxy) because I don't want to add more things to memory.

            How about changing the way Linux loads filesystems instead of complaining about the flavour of license? Seems to me like

          • by Bert64 (520050)

            But what plans do Oracle have?
            They are working on BTRFS, but will also soon be the owners of ZFS... What's to stop them re-releasing ZFS under compatible terms, or even merging the two filesystems?

            • They are working on BTRFS, but will also soon be the owners of ZFS... What's to stop them re-releasing ZFS under compatible terms, or even merging the two filesystems?

              Nothing I suppose, although I would prefer something as important as a filesystem be GPL'd just like the kernel, and not tied to any one company.

          • by hoggoth (414195)

            > Unfortunately, Sun had no plans on licensing ZFS so it could run on Linux. Will Oracle change it's mind? Probably not, hence the reason btrfs is reproducing features of ZFS.

            You are aware that Oracle is the company behind BTRFS and Oracle now owns Sun and ZFS?

            • You are aware that Oracle is the company behind BTRFS and Oracle now owns Sun and ZFS?

              I am aware. Also, Oracle licensed BTRFS under the GPL from the start. Makes it a lot easier to integrate with Linux when you don't have to make poor technical choices due to licensing issues.

        • Re: (Score:3, Informative)

          by Anonymous Coward

          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)

            by ToasterMonkey (467067)

            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.

        • by Anarke_Incarnate (733529) on Thursday April 30, 2009 @04:07PM (#27777897)
          I'm glad that you can assume a performance margin without knowing the workload or the application. Please, enlighten us with the performance of ZFS using Oracle or another database...Sure it can be fast, but please, in detail, explain the tunables that need to be set to achieve this performance and what kind of issues you may have with fsync and such, especially when dealing with SAN storage with external battery backed cache..... I am curious..... (and yet know the answers).
        • Re: (Score:1, Funny)

          by Anonymous Coward

          God I love slashdot! I *literally* pulled that quote out of my ass, and it's already been moderated up to 2, insightful.

        • by k8to (9046)

          Pull the other one. For any application with high transfer rates, the overhead of hashing the data with ZFS is likely to make it quite noticably worse performance-wise than a simpler filesystem like UFS or EXT3. Do some real-world benchmarks.

          I've seen cpu-limited apps reach beteen 130% and 200% of their ZFS performance when migrated to UFS.

    • Re: (Score:3, Interesting)

      by MikeBabcock (65886)

      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

      • by psyclone (187154)

        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.

        • by setagllib (753300)

          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.

      • by Znork (31774)

        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.

        • by idontgno (624372)

          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

          • by Znork (31774)

            As in, "take all the hard drives out of current machines

            Mmm, no. As in quit installing on local disk, bite the bullet and build a SAN and stick decent size disks in one or two linux machines servicing your block device needs. It'd expect the gp'd have at least one or two machines of the current ones that are stable enough to act as servers for the rest.

            Disparate sizes of disks isn't a problem as you share out lvm slices, and if you want maintenance ease and redundancy you mirror on the client side of the SA

            • by idontgno (624372)

              That's pretty much what I thought. Your technical solution is coherent, well-thought-out, clear, planned very well, and exactly not what original poster requested. I'm sure it's because you believe (and I agree) that what original poster requested is neither feasible nor practical.

              So, in short, other than your excellent but basically off-topic suggestion, your answer is "no."

              • by Znork (31774)

                that what original poster requested

                Looks like we have different interpretations of what the original poster requested.

                On one hand he asks for a specific solution: "I'm more interested in a truly distributed file system"

                On the other he states the intended purpose: "for making better use of my home LAN full of PCs with those over-sized hard drives that could be being used efficiently."

                As the posters suggested solution is infeasible but his stated purpose can be resolved I'd consider that a completely relevant

                • iSCSI isn't a distributed filesystem. And yes, several have been invented before, none of them very stable yet.

                  Centralized repository of data != Distributed & redundant storage system.

                  • by Znork (31774)

                    iSCSI isn't a distributed filesystem.

                    It is, however, a solution to more effective use of oversized hard drives; minimizing wasted space has always been one of the selling points of SAN storage. For the purpose, any block level storage protocol capable of supporting diskless machines would work, of course.

                    Centralized repository of data != Distributed & redundant storage system.

                    That would depend on your configuration. Most SAN storage solutions are distributed and redundant. You might not spread slices ar

      • Take a look at HAMMER, the new filesystem in DragonFlyBSD. It is designed for distributing load over the hard drives in a cluster, and sounds like exactly what you want.
      • Evgeniy Polyakov's Distributed Storage (DST) and Elliptics projects are along the lines of what you're thinking. DST is available in the latest testing kernel via the staging drivers series. See http://www.ioremap.net/taxonomy/term/2 [ioremap.net] and http://www.ioremap.net/taxonomy/term/17 [ioremap.net], respectively.

    • Re: (Score:1, Interesting)

      by Anonymous Coward

      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?

      ZFS

      --AC

      • by jabuzz (182671)

        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, Insightful)

      by UnknownSoldier (67820)

      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.

    • I thought so too, but I have noticed that deleting files on ext4 is faster than on ext3 on my dm-crypted drive.

    • by rvr777 (1082819)
      Yes, for you this may be the case. I also prefer data integrity in most of the cases, but sometimes you need the faster filesystem, because the data is not that important (temporary files), like cache and other data that will quickly be erased. So, like always, it depends on the needs of each environment.
    • by Hucko (998827)

      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.

  • by Smidge207 (1278042) on Thursday April 30, 2009 @02:56PM (#27776925) Journal

    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=

    • by thule (9041)

      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.

      • by jabuzz (182671)

        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.

    • by Chirs (87576)

      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.

      • 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

    • by RangerElf (32760)

      ...On the desktop, xfs will be the way to go.

      Why recommend xfs, when jfs is smaller and faster?

      • by jabuzz (182671)

        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.

    • 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

    • 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.

  • by rackserverdeals (1503561) on Thursday April 30, 2009 @03:13PM (#27777187) Homepage Journal

    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)

      by Anonymous Coward
      According to project leader Chris Mason the development of btrfs will continue:

      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]
    • by zaibazu (976612)
      On the positive side, a properly implemented ZFS in Linux would be awesome.
      • by Xabraxas (654195)

        On the positive side, a properly implemented ZFS in Linux would be awesome.

        Good luck getting ZFS into mainline. Even if the source is GPL'd it's not going to be an easy task. It has a lot of the same issues as Reiser4. There is a ton of stuff that Linus doesn't think should be in the filesystem itself but at another layer. There is a better chance that some concepts will make it into the kernel but I doubt the FS ever will.

    • by jhfry (829244)

      Why would you think that Btrfs is unstable and slow... because of one article where they tested an unfinished, un-optimized file system on a single computer with a simple single SATA drive.

      No filesystem performs the same on every device you use it on. Some very basic file systems do quite well on most drive/controller configurations, but anything truly advanced needs to be tuned for the configuration.

      Honestly, with all that btrfs has to offer, I could care less that it's marginally slower than EXT 3/4. Es

      • Why would you think that Btrfs is unstable and slow...

        There have been other Btrfs benchmarks. The main page of the Btrfs wiki [kernel.org] says:

        Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized, but it will only be changed if a critical bug is found and no workarounds are possible.

        If anything, one could hope that Oracle pulls some folks from ZFS to btrfs and actually speeds development, why develop two competing open file systems?

        If they were going to pick just one, why would they favor the one that is not done over the one that has been in production for years? Especially considering that more people deploy Oracle on Solaris/SPARC than on Linux?

        • by jhfry (829244)

          Why would you think that Btrfs is unstable and slow...

          There have been other Btrfs benchmarks. The main page of the Btrfs wiki [kernel.org] says:

          Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized, but it will only be changed if a critical bug is found and no workarounds are possible.

          The Wiki doesn't say it's unstable or slow at all... only that its not complete so they don't recommend it for production. It could be the fastest and most stable file system on the planet and still have that warning if the developers were not 100% confident that the disk format won't change.

          If anything, one could hope that Oracle pulls some folks from ZFS to btrfs and actually speeds development, why develop two competing open file systems?

          If they were going to pick just one, why would they favor the one that is not done over the one that has been in production for years? Especially considering that more people deploy Oracle on Solaris/SPARC than on Linux?

          The one that is done is not compatible with the linux kernel. Why do you think that Oracle started the btrfs project to begin with, they wanted something as feature rich as ZFS but would run on linux.

          It's possible tha

  • 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.

  • by Khashishi (775369) on Thursday April 30, 2009 @03:30PM (#27777425) Journal

    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)

      by vondo (303621)

      Because Phoronix does really crappy pointless benchmarks all the time. Occasionally they sucker me into reading them and I always wish I hadn't

  • try again (Score:1, Insightful)

    by Anonymous Coward

    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!

  • ZFS? (Score:2, Insightful)

    by javacowboy (222023)

    I didn't RTFA but why no mention of ZFS?

    • Re: (Score:2, Insightful)

      by pigeon768 (589860)

      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

    • by Slashcrap (869349)

      I didn't RTFA but why no mention of ZFS?

      Name: Mentions Java
      Signature: Mentions Macs
      Comment: Mentions ZFS for no reason.

      Congratulations! You have acheived the full trifecta of Slashdot faggotry!

  • Now all of my apps are killer apps!
  • by Anonymous Coward

    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

  • All these results just make me wonder why we arn't all using 'xfs' by default nowadays?

  • 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 say

"Even if you're on the right track, you'll get run over if you just sit there." -- Will Rogers

Working...