No announcement yet.

Benchmarking ZFS On FreeBSD vs. EXT4 & Btrfs On Linux

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31

    Your problem is obviously solved by a HW raid card, keep the rest as is.


    • #32
      Originally posted by kebabbert View Post
      The only reason to use ZFS, is your data is safe with ZFS. With all other common filesystems, you data slowly but surely gets corrupted. And the filesystem does not even notice this. This silent corruption is really bad. The examples are numerous.

      If you value a filesystem because of speed, then you have other priorities than Enterprise users (who value their data).
      first of all Raid5&6 do a pretty good job at data integrity. And for some reason, Solaris is not really a datacentre powerhouse, is it?

      But sure, ZFS is not about speed. What next? When BTRFS is finally seen as stable? 'ZFS is not about stability but licencing'?


      • #33
        Originally posted by energyman View Post
        But sure, ZFS is not about speed. What next? When BTRFS is finally seen as stable? 'ZFS is not about stability but licencing'?
        It goes much deeper than licensing. Even if ZFS were GPLv2 it would have an uphill battle to get into the kernel. Not to criticize Sun's (rather radical) architectural decisions regarding ZFS... but it is important to remember that they were *Sun's* decisions. Even reiser4 was not such a "rampant layering violation", wrt Linux's architectural expectations, as ZFS. And look what a time it's had. (Of course, Hans' attitude didn't help.) ZFS may be a great fit for the Solaris kernel. But that doesn't mean it's a good fit for the Linux kernel. I'm just about 101% sure that btrfs was the only sane way forward. And fortunately, it is proceeding remarkably smoothly, and faster than I might have expected.

        ZFS is a great 8 ohm speaker connected to the 8 ohm amp called Solaris. btrfs is a great new 4 ohm speaker, still under construction, that connects to the 4 ohm amp of Linux. Which is better for Linux? You have to look at the impedance first, and then consider the other details of relative performance. ("Performance" in this case, encompassing everything else, and not just speed.)


        • #34
          Originally posted by kebabbert View Post
          That is cool.... lots of UNTRUE things about Sun summarily snipped...
          How long have you dealt with the Sun experts? I have dealt with them for MANY MANY MANY years (20+). Let me tell you first hand that these guys are MASTER of the untruth. They will hide their bugs and problems for YEARS... and then after they feel safe, they will let you into their "secrets" and show you just HOW BAD their code really was.

          I'm sorry... but you're drinking poison kool-aid and you do not realize it.

          Do you read the forums? Do you SEE the problems that people are having with ZFS? Now.. btrfs isn't ready for consumption.. sure... but I REALLY don't think you'll be taking any bigger risk right now... seriously... I think btrfs might be more enterprise ready than ZFS. Why is this?

          Ok.. so we have different opinions about Sun's expertise (expertise that bankrupt the company btw). That's ok... but I just want to make sure that people understand, there is ANOTHER side to the story apart from the slick marketing and persuasive arguments that Sun and its engineers tell.


          • #35
            It is nice to see filesystems tested. Just be aware that this is probably the most difficult part of a computer system to understand with regards to performance. Also testing ZFS and BtrFS on a single drive laptop is like testing your new racing car tires and suspension in the city during rush our. Yes they will perform nice, and no you haven't got a clue about their real capabilities. To find that you need at least multi core CPU and multiple drives. Preferably also flash caches, multiple gigabytes of RAM and high throughput host bus adapters.

            At the moment it is however not much point in benchmarking BtrFS. AFAIK it's optimization is broken and can lead to massive internal fragmentation which may cause the filesystem not to be able to write even if half your disk is "free".

            As for BtrFS vs ZFS: ZFS is the only one to consider today for production. BtrFS might have a longterm advantage over ZFS. They are basically very similar and will likely get similar features over time, except BtrFS has a much more complicated data structure than ZFS (modified b-tree vs binary tree for ZFS). This complex datastructure will be what makes or brakes BtrFS in the long run. So far it has proven difficult to optimize.

            128bit file systems would have been stupid. Far too much address calculation hassle on a 64bit CPU. Good thing ZFS really is a 64bit volume manager tightly integrated with a 64bit file system. If you ever, in the future, need 65bit or more address space in a single file system, for whatever reason I can't grasp, then ZFS can't help you. It will however happily give you almost 64? 64bit file systems. Which is much more manageable.


            • #36
              One thing I really like:
              FreeBSD vs Linux, Linux win. Freebse fanbois 'no fair, different userland'
              Debian/FreeBSD vs Debian/Linux. Debian/Linux wins. Freebse fanbois 'you should try the new drivers they speed thing up a lot. And ZFS. It is surely faster'
              FreeBSD with the new sata driver - shows slowdowns. Freebse fanbois ignore that and just pound the fs drum. 'Try ufs with journaling! And ZFS rocks performancewise'.
              FreeBSD with UFS+Journaling and ZFS vs Linux. Linux wins. By a large margin. Freebse fanbois 'no fair, ZFS never was about speed but data integrity'.



              • #37
                ZFS and BtrFS are both a lot about performance in multiple disk scenarios. Neither is really made for single drive performance. If you want single drive performance then ext2/3/4 with aggressive and unsafe settings is best by a long shot.


                • #38
                  no, reiser4 is the best by a long shot. With compression you get checksuming for free.It is also atomic. So some data loss scenarios with btrfs just don't happen with reiser4.


                  • #39
                    Well as always with performance this needs to be modified with a "that depends on the workload". If you have compression on and use a slow CPU and precompressed data then performance will not be much to write home about.


                    • #40
                      there is a reason that you can chose between lzo and gzip AND reiser4 only tries to compress compressable stuff. But another fact is: with todays slow harddrives any CPU is fast enough.