Announcement

Collapse
No announcement yet.

Linux 4.4 To 4.7 - EXT4 vs. F2FS vs. Btrfs Benchmarks

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by dangerousHobo View Post
    I would like to see how XFS compared to the rest in this test.
    I can tell you one thing already ... XFS is more prone to corruption as it's not atomic.

    Comment


    • #32
      Originally posted by andre30correia View Post
      btrfs always the worst, and a lot of regressions since kernel 4.4
      I have seen quite some regressions on ext4 and XFS too.

      It's the slowest because the data is *always* consistent. Either old data and metadata OR new data and new metadata. XFS, ext4 don't have that. This consistency takes time yes.

      Comment


      • #33
        Originally posted by drSeehas View Post
        Why was ZFS omitted?
        the license is IRL in some environments also a problem. Next is that you don't currenbtly want a port of ZFS in linux. Try under solaris et al. There it's extremely well. Under BSD -- lost quite some data there. Luckily data that can be regenerated.

        Comment


        • #34
          Originally posted by roelandjansen View Post
          ... the license is IRL in some environments also a problem.
          And this is a reason to not include a ZFS benchmark?

          Next is that you don't currenbtly want a port of ZFS in linux. ...
          Why?
          Last edited by drSeehas; 16 August 2017, 08:41 AM.

          Comment


          • #35
            Originally posted by drSeehas View Post
            And this is a reason to not include a ZFS benschmark?
            No the reason was already given directly afetr you asked the question. However, bear in mind that in an enterprise environment, those license issues generally exclude the use of ZFS. Hence, posting results of a filesystem "you" cannot use is not really making sense to me.

            and why:


            Next is that you don't currenbtly want a port of ZFS in linux. ...
            is pretty simple. We have seen massive corruption of ZFS pools several times on FreeBSD while on the Solaris et all we never seen this.
            Now, the pools on the FreeBSD environments was data that could be regenerated so that was not a panic moment.

            You might not have done much debugging on ZFS yet when all dies.

            Don't get me wrong, ZFS on the native OS is great stuff and is fully useable. Hwever mixed environments are painful and sometimes just not possible.

            So, I did not write much new here; read and try to understand; ouor situation may very well not apply to your situation. But the bottom line is that ZFS is not interesting if it cannot be used. For US.

            Comment


            • #36
              Originally posted by roelandjansen View Post
              ... in an enterprise environment, those license issues generally exclude the use of ZFS. ...
              ???
              How can the CDDL exclude the use of ZFS in an enterprise environment?

              Comment


              • #37
                Originally posted by drSeehas View Post
                ???
                How can the CDDL exclude the use of ZFS in an enterprise environment?
                There's no problem to use it in enterprise environment. You just have to make it clear what a company can and cannot do in order to avoid copyright infringement, it's simple and easy to understand for any decision maker.

                Comment


                • #38
                  This post discusses an atypical GPL violation. Unlike most GPL violations Conservancy faces, in this case, a third-party entity holds a magic wand that can instantly resolve the situation. Oracle is the primary copyright holder of ZFS, and, despite nearly eight years (going back to the days of Sun's control of the code) of the anti-license-proliferation community's urging, Oracle continues to license their code under their own, GPL-incompatible license. While this violation has many facets, and Oracle did not themselves violate GPL in this specific case, they hold the keys to this particular kingdom and they forbid the Linux community to enter. While there are complexities that we must address, in this context, Oracle could make everyone's life easier by waving their magic relicensing wand. Nevertheless, until they do, since GPL-incompatible licenses are the root of all GPL violations, combinations of GPL'd code with Oracle's GPL-incompatible code yield GPL violations, such as the ongoing violation by Canonical, Ltd.


                  It's not compatibl with the GPL.

                  Also, RHEL for instance will not support your system at all. SUSE may be a bit different though.


                  Comment


                  • #39
                    Originally posted by roelandjansen View Post
                    https://sfconservancy.org/blog/2016/...zfs-and-linux/

                    It's not compatibl with the GPL. ...
                    No!
                    This is just another opinion.
                    Maybe it is reverse and the GPL is not compatible with the CDDL?
                    Went anyone to court?

                    Comment

                    Working...
                    X