Slashdot Mirror

← Back to Stories (view on slashdot.org)

Btrfs Is Not Yet the Performance King

Posted by timothy on 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."

117 comments

  1. hmm by Anonymous Coward · · Score: 0, Funny

    what I want to know is, which filesystem is most helpful for murdering my Russian wife?

    1. Re:hmm by TooMuchToDo · · Score: 3

      Where's the "-1, tired and worn out" mod option?

    2. Re:hmm by laejoh · · Score: 1

      In Soviet Russia?

  2. Stability, reliability by Hatta · · Score: 4, 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?

    --
    Give me Classic Slashdot or give me death!
    1. Re:Stability, reliability by Cassini2 · · 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 for more links.

      With file systems, speed and data integrity are trade-offs.

    2. Re:Stability, reliability by MikeBabcock · · Score: 2, 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 and have all my PCs form a darknet with each other.

      --
      - Michael T. Babcock (Yes, I blog)
    3. Re:Stability, reliability by Anonymous Coward · · Score: 1, Interesting

      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

    4. Re:Stability, reliability by Anonymous Coward · · 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.

    5. Re:Stability, reliability by psyclone · · Score: 1

      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 or Hadoop 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.

    6. Re:Stability, reliability by UnknownSoldier · · 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.

    7. Re:Stability, reliability by Znork · · Score: 1

      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.

    8. Re:Stability, reliability by TooMuchToDo · · Score: 3, Informative

      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.

    9. Re:Stability, reliability by jabuzz · · Score: 1

      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.

    10. Re:Stability, reliability by onefriedrice · · Score: 4, Insightful

      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.

      --
      This author takes full ownership and responsibility for the unpopular opinions outlined above.
    11. Re:Stability, reliability by Anonymous Coward · · 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.

    12. Re:Stability, reliability by Anarke_Incarnate · · Score: 3, Informative

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

    13. Re:Stability, reliability by TooMuchToDo · · Score: 0, Troll

      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.

    14. Re:Stability, reliability by Anarke_Incarnate · · Score: 1

      What happens when that disk goes loose? Do you have to tighten her back up or just ask for a daddy stitch?

    15. Re:Stability, reliability by idontgno · · Score: 1

      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 actually address GP's original requirements, which is a distributed filesystem using spare capacity on existing client systems' current directly-attached JBOD disks.

      --
      Welcome to the Panopticon. Used to be a prison, now it's your home.
    16. Re:Stability, reliability by Anonymous Coward · · Score: 1, Funny

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

    17. Re:Stability, reliability by Anonymous Coward · · Score: 0

      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.

      As it stands, GPL compatible software is the only software that matters when it comes to kernel-linked stuff.

    18. Re:Stability, reliability by Nevyn · · Score: 4, 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.

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
    19. Re:Stability, reliability by Anonymous Coward · · Score: 1, Funny

      You have a very weird way of storing quotes.

    20. Re:Stability, reliability by rackserverdeals · · Score: 2, 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.

      --
      Dual Opteron < $600
    21. Re:Stability, reliability by ChienAndalu · · Score: 1

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

    22. Re:Stability, reliability by setagllib · · Score: 1

      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.

      --
      Sam ty sig.
    23. Re:Stability, reliability by SpaceLifeForm · · Score: 1

      Probably desired due to the low latency.

      --
      You are being MICROattacked, from various angles, in a SOFT manner.
    24. Re:Stability, reliability by rvr777 · · Score: 1

      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.

    25. Re:Stability, reliability by Hucko · · Score: 1

      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.

      --
      Semi-automatic amateur armchair Australian philosopher; conjecture ready at any moment...
    26. Re:Stability, reliability by JackieBrown · · Score: 1

      I guess that explains why no non-gpl stuff is on my Debian install.

      Oh wait...

    27. Re:Stability, reliability by Anonymous Coward · · Score: 0

      Yeah and feel free to whine when your GPL code is attacked in a lawsuit due to patent infringement.

    28. Re:Stability, reliability by Luke+has+no+name · · Score: 1

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

    29. Re:Stability, reliability by ToasterMonkey · · Score: 2, 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.

    30. Re:Stability, reliability by Anonymous Coward · · Score: 0

      Because no one is using Sun's OS, hence why they were bought out.

    31. Re:Stability, reliability by Anonymous Coward · · Score: 0

      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

      I don't know what you're getting at. ALL cooked filesystems need app minded tuning for best performance.. especially on anything with RAID, especially expensive software running on expensive RAID, ie SAN equipment. Even the devices themselves are tuned specifically for certain workloads, RAID 10 for DBs is common, RAID 3 for streaming, and so on.
      There's block size, alignment, prefetch settings, log/journal/ZIL options, direct IO, etc. but these apply to any FS where performance is concerned.

      BTW,

      SAN storage with external battery backed cache

      Is there any other kind?

      I am curious..... (and yet know the answers).

      I have to wonder what you were getting at by asking these questions?

    32. Re:Stability, reliability by LingNoi · · Score: 0

      You're making the assumption that everyone lives in the US with its messed up patent system. For some of us software patents aren't an issue at all.

    33. Re:Stability, reliability by k8to · · Score: 1

      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.

      --
      -josh
    34. Re:Stability, reliability by Rhinobird · · Score: 1

      You should see how insightful he gets after eating cabbage and beans.

      --
      If Mr. Edison had thought smarter he wouldn't sweat as much. --Nikola Tesla
    35. Re:Stability, reliability by Sentry21 · · Score: 1

      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.

    36. Re:Stability, reliability by ultrabot · · Score: 1

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

      --
      Save your wrists today - switch to Dvorak
    37. Re:Stability, reliability by Anonymous Coward · · Score: 0

      Ok, then remove the "accidentally". I have a single enclosure of disks in a data center with limited space. Because of site logistics, that enclosure has to last me essentially forever while my storage needs keep increasing. No problem - I'm planning ahead. I'll always keep one slot free, and as disk capacities grow I'll periodically add a large drive, transfer all of my smallest drive's data to it, and get rid of the smallest drive.

      Except I can't do that with ZFS. I can *never* get rid of a drive without having some other identical storage space to dump the whole pool to and then dump it back. ZFS's design philosophy is that I can always add more disks, but I'm space-constrained - I only get the one rack and it's got to be pretty near full all the time otherwise someone else will be assigned the space. And even if I did have the spare space somewhere on some ungodly stack of tapes, I'll have downtime for the entire duration of the restore.

      This isn't a pie-in-the-sky feature. It's been in LVM for years, and I can do the expansion without any downtime.

    38. Re:Stability, reliability by Anonymous Coward · · Score: 0

      Will Oracle change it's mind? Probably not, hence the reason btrfs is reproducing features of ZFS.

      Oracle does a lot of the btrfs development. So if they could simplify their work by releasing ZFS under the GPL, they may very well do that.

    39. Re:Stability, reliability by Luke+has+no+name · · Score: 1

      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.

    40. Re:Stability, reliability by Ginger+Unicorn · · Score: 1

      Sun could have dual licenced ZFS under GPL and BSD. Why didn't they?

      --
      (1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
    41. Re:Stability, reliability by Anonymous Coward · · Score: 0

      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.

      Other free licenses such as the Sun CDDL, yes? Licenses that were written long after the GPL was, yes? Yeah, clearly the GPL is to blame there.

      Let's be honest: we all know that Sun wrote the CDDL and put ZFS etc. under it in order to a) be able to claim they were adhering to FOSS principles, and b) make sure that their competitors (such as Linux) would not be able to benefit from their stuff (e.g. by porting ZFS to Linux, although I'll note that the lack of a flow of code works both ways - Solaris can't incorporate code from Linux, either). And that's certainly entirely fine, too - Sun's entirely free to do that.

      But don't go around spreading lies about how this was not a deliberate move on Sun's part or how it's the fault of the GPL that a license that came into being 15 years *after* the GPL intentionally broke compatibility with it (i.e., the GPL).

      We're not THAT stupid here.

    42. Re:Stability, reliability by TheRaven64 · · Score: 1

      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.

      --
      I am TheRaven on Soylent News
    43. Re:Stability, reliability by chrish · · Score: 1

      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 it would be faster and less bug-prone that implementing a new filesystem.

      --
      - chrish
    44. Re:Stability, reliability by chrish · · Score: 1

      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 filesystems without being merged into the kernel (or is it? I honestly don't know)?

      --
      - chrish
    45. Re:Stability, reliability by Bert64 · · Score: 1

      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?

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    46. Re:Stability, reliability by Bert64 · · Score: 1

      I don't see why they really have to compete... Sun sell hardware and support packages, do they really care what you run on their hardware so long as it's sun hardware and comes with a lucrative maintenance contract?

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    47. Re:Stability, reliability by asaul · · Score: 1

      No - but you are reading it the way you want - lets go over this again.

      Sun wanted to Open Source Solaris because it was the cool thing to do at the time.
      However there was non-Sun code which could not be released. Also Sun as a OS provider had vendors who wrote kernel modules for Solaris. According to the interpretations of kernel modules under GPL, putting Solaris or any of Sun's kernel code under the GPL required the rest of the kernel to be GPL - not suitable for other vendors who did not wish to GPL their code. Argue that if you want, but find a corporate lawyer who wont read the GPL conservatively.

      So - Sun wrote the CDDL in order to have a license which met their needs and their vendors and partners needs, and then released their code.

      So now in the minds of Linux fanbois everywhere, Solaris goes from being a closed evil proprietary operating system trying to kill linux with lockin, to a open source evil operating system trying to undermine Linux by tempting it with code that it cannot integrate.

      So - why not dual license Linux if you want the code so bad?

      What I find funny is the number of posts that on one hand flog ZFS for being inferior to any Linux filesystem for so many ill informed reasons, then decry it for not being GPL and hence not available in Linux.

      --
      "If everybody is thinking alike, somebody isn't thinking" - Gen. George S. Patton
    48. Re:Stability, reliability by asaul · · Score: 1

      I am assuming you have some sort of redundancy in your pool configuration, this being your uber always running data center machine that in no way is using USB disks.

      So as you have either RAID-Z or mirrored vdevs, in both cases you an offline one of the devices, replace it with a larger one, then resilver the pool. Once you have replaced the devices in the vdev with larger ones, the pool will automatically resize.

      But your point is taken - the ability to remove devices permanently is a basic administration feature which is lacking currently, but the work is underway. From what I understand the model used to do it opens up a number of useful methods for playing with zpools

      --
      "If everybody is thinking alike, somebody isn't thinking" - Gen. George S. Patton
    49. Re:Stability, reliability by TooMuchToDo · · Score: 1

      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.

    50. Re:Stability, reliability by Znork · · Score: 1

      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 SAN, not on the server side.

      a distributed filesystem using spare capacity

      There is none, nor is there likely to be one in the near future. You can accomplish something towards that end with hacks like freenet, or, heck, you could even share the space as block iscsi storage and raid it on other nodes, but the combination of varying client types, varying client uptimes, varying client versions, etc, and any such system will become massively painful to maintain, would be a horror to program for or would have to have massive redundancy to deal with random data going unavailable at any time.

      The (stable functional) distributed filesystems there are tend to be written for either large clusters of homogenous clients or are merely designed to redundantly serve from several servers. Neither is a good solution to that particular problem, and trust me, I looked (four years ago, before going with SAN). I haven't seen any major new developments since then. Well, except SSD disks, which, if I just wanted a quick solution, would probably be the way to go to minimize storage waste on new clients today.

    51. Re:Stability, reliability by ultrabot · · Score: 1

      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.

      --
      Save your wrists today - switch to Dvorak
    52. Re:Stability, reliability by Anonymous Coward · · Score: 0

      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.

      Obviously, as the owner of ZFS, Sun can open source their product under their license AND the GPL. Your remark is common of the Sun employee's I've spoken with about this: playing innocent doe-in-the-headlight kinda stuff. Anyway, this leads one to conclude: 1) either the licensing boy's at Sun are STUPID, or 2) ZFS is intentionally incompatible with the GPL.

      You don't think the employees of Sun are stupid, do you?

      C//

    53. Re:Stability, reliability by mhall119 · · Score: 1

      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.

      --
      http://www.mhall119.com
    54. Re:Stability, reliability by mhall119 · · Score: 1

      Also Sun as a OS provider had vendors who wrote kernel modules for Solaris. According to the interpretations of kernel modules under GPL, putting Solaris or any of Sun's kernel code under the GPL required the rest of the kernel to be GPL - not suitable for other vendors who did not wish to GPL their code. Argue that if you want, but find a corporate lawyer who wont read the GPL conservatively.

      Since Sun has copyright on the Solaris kernel, they could have released it under the GPL while simultaneously licensing it under whatever other licensing agreement they had with other vendors.

      If you license your code under the GPL, that doesn't prohibit you from licensing it under any other terms. You can distribute your own code under as many licenses as you want.

      Sun wrote the CDDL in order to have a license which met their needs and their vendors and partners needs, and then released their code.

      Sun could have dual-licensed it under the CDDL and GPL. They could have used an Apache or BSD license. There were plenty of options available if Sun wanted to allow the distribution of a ZFS as a Linux kernel filesystem.

      why not dual license Linux if you want the code so bad?

      Because Linus never required copyright assignment for code he accepted. Thus, Linus can only legally distribute the Linux kernel under the GPLv2, as he can't relicense someone else's code.

      --
      http://www.mhall119.com
    55. Re:Stability, reliability by Anonymous Coward · · Score: 0

      The GPL restricts code that is *linked* to other GPL code. Filesystems have to link to the kernel. License knowledge fail.

    56. Re:Stability, reliability by hoggoth · · Score: 1

      > 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?

      --
      - For the complete works of Shakespeare: cat /dev/random (may take some time)
    57. Re:Stability, reliability by TooMuchToDo · · Score: 1

      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.

    58. Re:Stability, reliability by idontgno · · Score: 1

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

      --
      Welcome to the Panopticon. Used to be a prison, now it's your home.
    59. Re:Stability, reliability by Znork · · Score: 1

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

    60. Re:Stability, reliability by wild_berry · · Score: 1

      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 and http://www.ioremap.net/taxonomy/term/17, respectively.

    61. Re:Stability, reliability by MikeBabcock · · Score: 1

      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.

      --
      - Michael T. Babcock (Yes, I blog)
    62. Re:Stability, reliability by Znork · · Score: 1

      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 around on every node; you could, but that would simply be impractical.

      It's entirely up to you, of course. If you want to make better use of those over-sized hard drives, SAN is the only way to go. If you want a distributed filesystem to do the same thing, well, there are none.

    63. Re:Stability, reliability by Ginger+Unicorn · · Score: 1

      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?

      --
      (1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
  3. How is this news? by Burkin · · Score: 3, Insightful

    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?

    1. Re:How is this news? by Anonymous Coward · · Score: 0

      Mod parent up. Seriously.

    2. Re:How is this news? by fatp · · Score: 1

      The newsworthy part is that the less tested and less stable filesystem in beta (or alpha?) can complete the tests.

  4. Numbers for mysql performance on BTRFS? by Smidge207 · · 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=

    --
    Is it just my observation, or is eldavojohn an idiot?
    1. Re:Numbers for mysql performance on BTRFS? by thule · · Score: 1

      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.

    2. Re:Numbers for mysql performance on BTRFS? by Chirs · · Score: 1

      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.

    3. Re:Numbers for mysql performance on BTRFS? by Anonymous Coward · · Score: 0

      If I might guess, even though postgres compares well to oracledb on most benchmarks, oracledb will be far, far faster than postgres on btrfs.

      Just, you know, a hunch.

    4. Re:Numbers for mysql performance on BTRFS? by RangerElf · · Score: 1

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

      Why recommend xfs, when jfs is smaller and faster?

    5. Re:Numbers for mysql performance on BTRFS? by jabuzz · · Score: 1

      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.

    6. Re:Numbers for mysql performance on BTRFS? by jabuzz · · Score: 1

      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.

    7. Re:Numbers for mysql performance on BTRFS? by RiotingPacifist · · Score: 1

      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

      --
      IranAir Flight 655 never forget!
    8. Re:Numbers for mysql performance on BTRFS? by thule · · Score: 1

      You are correct, I should have left off the '2'

  5. What will happen to Btrfs by rackserverdeals · · Score: 2, 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?

    --
    Dual Opteron < $600
    1. Re:What will happen to Btrfs by Anonymous Coward · · Score: 2, Interesting

      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

    2. Re:What will happen to Btrfs by zaibazu · · Score: 1

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

    3. Re:What will happen to Btrfs by Xabraxas · · Score: 1

      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.

      --
      Time makes more converts than reason
    4. Re:What will happen to Btrfs by jhfry · · Score: 1

      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. Especially if I can spread data over multiple disks, with redundancy, and no need for software raid to add to the overhead.

      Your question is very poorly worded. Better would be, "Should we expect the Oracle and Sun merger to slow or halt development on btrfs in favor of the proven ZFS." To which I would say no... BTRFS is already in the kernel, ZFS stands little chance.

      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?

      --
      Sometimes the best solution is to stop wasting time looking for an easy solution.
    5. Re:What will happen to Btrfs by rackserverdeals · · Score: 1

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

      There have been other Btrfs benchmarks. The main page of the Btrfs wiki 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?

      --
      Dual Opteron < $600
    6. Re:What will happen to Btrfs by jhfry · · Score: 1

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

      There have been other Btrfs benchmarks. The main page of the Btrfs wiki 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 that they will drop BTRFS in favor of pushing Solaris/ZFS, but I doubt it.

      --
      Sometimes the best solution is to stop wasting time looking for an easy solution.
  6. filesystem config for each case? by Chirs · · Score: 1

    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.

  7. format stability by Anonymous Coward · · Score: 0

    So far I have resisted moving to butterface because I've read that the on-disk format may change, and I'd have to reformat and copy all my data to and from a backup device. It wasn't a pain I wanted to go through just for that.

    So I'm happily on XFS for now - I'm very happy with the large file performance and xfs_fsr is nice to have. Will try butterface at some point in the future if it reaches format stability.

    1. Re:format stability by Dan+Ost · · Score: 1

      What's the advantage of XFS over ext3?

      --

      *sigh* back to work...
    2. Re:format stability by Anonymous Coward · · 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 but also use it on a desktop machine. It's also hugely scalable.

    3. Re:format stability by pigeon768 · · 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.

    4. Re:format stability by AaronW · · Score: 1

      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.
    5. Re:format stability by bzipitidoo · · Score: 1

      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"
    6. Re:format stability by Xabraxas · · Score: 1

      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
    7. Re:format stability by macshit · · Score: 1

      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....
  8. several useless metrics by Khashishi · · Score: 2, 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.

    1. Re:several useless metrics by vondo · · Score: 2, 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

    2. Re:several useless metrics by Anonymous Coward · · Score: 0

      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.

      Because "Phoronix" is incorrectly spelled.

      The correct spelling is "Moronix".

      As in "bunch of morons who don't know what they're doing playing with computers".

  9. try again by Anonymous Coward · · Score: 1, Insightful

    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!

  10. Better or Butter? by Anonymous Coward · · Score: 0

    Does one pronounce Btrfs as "Better FS" or "Butter FS"? I prefer the latter.

    1. Re:Better or Butter? by Anonymous Coward · · Score: 1, Interesting

      "But her face"

      As in, she's so hot...but her face.

    2. Re:Better or Butter? by nicodoggie · · Score: 1

      But does it matter? You know everything's better with butter.

    3. Re:Better or Butter? by JackieBrown · · Score: 1

      That's what bags are for

  11. ZFS? by javacowboy · · Score: 2, Insightful

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

    --
    This space left intentionally blank.
    1. Re:ZFS? by Anonymous Coward · · Score: 0

      ZFS is only available in Linux as a user-space filesystem using FUSE due to the GPL not being compatible with the CDDL used for ZFS.

    2. Re:ZFS? by pigeon768 · · 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 implementation is useless (slow + unstable) and everyone knows it.

    3. Re:ZFS? by Slashcrap · · Score: 1

      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!

  12. Boot Performance is Critical? by Anonymous Coward · · Score: 0

    Fedora 11 even took longer to boot when using Btrfs than EXT3 or EXT4."

    Performance testing is a huge part of my job. File system performance is a critical part of many performance tests.

    In 20 years of performance testing, I have never measured or reported on "boot performance". After all, who among us reboots more than once every 6 or 7 months?

    1. Re:Boot Performance is Critical? by Anonymous Coward · · Score: 0

      uh people who don't run enterprise linux? people who power down their machines when not using them to save on utilities?

  13. ReiserFS all the way! by hansede · · Score: 1, Funny

    Now all of my apps are killer apps!

  14. Put the money where it matters... by mcrbids · · Score: 1

    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.
  15. No large file unlink() benchmarks? by Anonymous Coward · · Score: 1, Interesting

    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.

  16. xfs? by John+Meacham · · Score: 1

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

    --
    http://notanumber.net/
  17. ReiserV4 vs BTRFS by Anonymous Coward · · Score: 0

    Would be nice to have a Benchmark between the KillerFS(ReiserV4) and BTRFS!

  18. One drive? by jhfry · · Score: 1

    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.
  19. Designed for database usage? Not. by butlerm · · Score: 1

    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.