Announcement

Collapse
No announcement yet.

OpenSUSE Looks To Switch To Btrfs For Next Release

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

  • #31
    Originally posted by RahulSundaram View Post
    That is a naive claim. Are you a developer at all? It is impossible to automate all use cases when testing anything as complex as a filesystem.
    It should be possible to test most use cases, if there are one or more full time testers who will create new or use existing realistic tests for all common real world software like database server.

    Comment


    • #32
      Originally posted by JS987 View Post
      It should be possible to test most use cases, if there are one or more full time testers who will create new or use existing realistic tests for all common real world software like database server.
      it's not about having the time to create the tests. It's about actually knowing all of the world's use cases.

      Which you can't, really.

      Comment


      • #33
        Originally posted by erendorn View Post
        it's not about having the time to create the tests. It's about actually knowing all of the world's use cases.
        Which you can't, really.
        Proper testing would still reduce number of bugs significantly.

        Comment


        • #34
          Originally posted by Luke_Wolf View Post
          Also Larabel appears to have missed a paragraph (ftfs):

          (emphasis mine)
          So that means they're looking at 13.2 having it by default not 13.1
          The article never claimed otherwise. "Next" does not necessarily mean 13.1.

          Comment


          • #35
            Originally posted by JS987 View Post
            Proper testing would still reduce number of bugs significantly.
            It will and it has reduced the number of bugs from where it would be if there was no automatic or manual testing, both of which every major filesystem in Linux has. Several major vendors (Red Hat, Oracle, Novell) including an entire storage company (Fusion IO) which has hired several of the Btrfs developers do this because their entire business depends on this capability.

            Comment


            • #36
              Originally posted by GreatEmerald View Post
              The article never claimed otherwise. "Next" does not necessarily mean 13.1.
              Actually yes it does, in terms of futures "Next" is a very specific term meaning "The one after the current one", and openSUSE.Release.Current = 12.3

              from http://www.merriam-webster.com/dictionary/next
              1next
              adjective \ˈnekst\

              : coming after this one : coming after the one that just came, happened, etc.

              : any other
              Full Definition of NEXT
              1
              : immediately adjacent (as in place, rank, or time)
              2
              : any other considered hypothetically <knew it as well as the next man>
              If he wanted to speak of a future release "later", "future", etc.. would be a proper generic term for a release in the future that is not necessarily the next one.

              Comment


              • #37
                BTRFS is still no where near ready... yet

                BTRFS has a serious Achilles heel and... ironically its COW & snapshots...
                Every time a snapshot is made, it?s b-tree changes, and when it changes, that forces the entire file system structure (b+tree) to be modified and duplicated on each file system snapshot.
                So that creates an exponential degradation each and every time a snapshot is performed simply because its COW feature is working against it really badly.
                So... the very benefit BTRFS has as its best feature its always defended for(snapshots) completely makes the file system into a ticking data-time-bomb until there?s an exponential metadata overload to the point of a grinding halt and system freeze, just because there are too many nodes created by the snapshots which cause that exponential b-tree node duplication.


                This is a very serious reason to NOT USE BTRFS AS DEFAULT BECAUSE ALL BTRFS FILE SYSTEMS WILL NEED TO BE DESTROYED AND RECREATED IF/WHEN THIS PROBLEM IS EVER SOLVED.


                Also, all the REAL databases like Postgres, Oracle, MSSQL and MySQL etc, have realized that the only true way to be consistent and able to not be insane after the end of an error frenzy, is to append to their transaction log, and they seem extremely separated with their internal structures etc so if anyone COULD have found a way to not use a single log to contend on, it would be them.

                I really do apologize for caps but hasty use of BTRFS is a BAD IDEA still, please stick to EXT4 or XFS.

                Comment


                • #38
                  come back in a few years and let me know when Butter Face will be ready as it looks like shit to me and has way to many bugs and missing way to many things to be called ready i don't even know why they call it stable at all or is it stable for testing

                  Comment


                  • #39
                    Originally posted by HeavensRevenge View Post
                    BTRFS has a serious Achilles heel and... ironically its COW & snapshots...
                    Every time a snapshot is made, it?s b-tree changes, and when it changes, that forces the entire file system structure (b+tree) to be modified and duplicated on each file system snapshot.
                    So that creates an exponential degradation each and every time a snapshot is performed simply because its COW feature is working against it really badly.
                    So... the very benefit BTRFS has as its best feature its always defended for(snapshots) completely makes the file system into a ticking data-time-bomb until there?s an exponential metadata overload to the point of a grinding halt and system freeze, just because there are too many nodes created by the snapshots which cause that exponential b-tree node duplication.


                    This is a very serious reason to NOT USE BTRFS AS DEFAULT BECAUSE ALL BTRFS FILE SYSTEMS WILL NEED TO BE DESTROYED AND RECREATED IF/WHEN THIS PROBLEM IS EVER SOLVED.


                    Also, all the REAL databases like Postgres, Oracle, MSSQL and MySQL etc, have realized that the only true way to be consistent and able to not be insane after the end of an error frenzy, is to append to their transaction log, and they seem extremely separated with their internal structures etc so if anyone COULD have found a way to not use a single log to contend on, it would be them.

                    I really do apologize for caps but hasty use of BTRFS is a BAD IDEA still, please stick to EXT4 or XFS.
                    Valerie Aurora said, in the mentioned lwn article, that that is why, in the past, btrees and COW were thought to be ill wed to one another. That's why they aren't using btrees, but modified btrees (according to ohad rodeh's paper "B-trees, shadowing and clone") to avoid this problem.

                    Comment


                    • #40
                      Originally posted by Luke_Wolf View Post
                      Actually yes it does, in terms of futures "Next" is a very specific term meaning "The one after the current one", and openSUSE.Release.Current = 12.3
                      13.1 comes after this one, 12.3. So does 13.2. It doesn't come before 12.3. Also note that even with the meaning of being a single one after the current one, 13.2 is the next development version.

                      Originally posted by HeavensRevenge View Post
                      BTRFS has a serious Achilles heel and... ironically its COW & snapshots...
                      You clearly have never used Btrfs.

                      Comment

                      Working...
                      X