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


                      • #41
                        Originally posted by liam View Post
                        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.
                        Well, of course it's something I thought they would have avoided but there's countless reports of people saying their BTRFS installations slow to grinding haults ~4 months after installation and simply migrating to EXT4 makes them feel magnitudes faster. Also there was a nice presentation of a dev showing a scatter-plot of disk access times and how BTRFS exponentially degraded over a 22 hour test of hardcore usage and stressing the FS for metadata-intensive workloads.
                        http://opensuse.14.x6.nabble.com/Btr...td4994291.html is a good record of many people confirming this exact problem manifesting and that they did NOT get this right.

                        Originally posted by GreatEmerald View Post
                        You clearly have never used Btrfs.
                        Of course I have, but always only for testing and I never used it long term beyond 2 weeks or so. You're all bigger men than I am to trust my root to BTRFS that's all I've got to say, and I experiment with some pretty crazy stuff like distcc distributed compiles lol, but no way would I ever trust my data to BTRFS at this moment of it's lifetime.

                        Comment


                        • #42
                          Originally posted by GreatEmerald View Post
                          13.1 comes after this one, 12.3. So does 13.2. It doesn't come before 12.3.
                          Did you read the dictionary definition I linked to you? If you don't like Merriam-Webster here's Oxford
                          http://oxforddictionaries.com/us/def...sh/next?q=next
                          next
                          Syllabification: (next)
                          Pronunciation: /nekst/
                          adjective

                          1(of a time or season) coming immediately after the time of writing or speaking:we’ll go next year next week’s parade
                          (of a day of the week) nearest (or the nearest but one) after the present:not this Wednesday, next Wednesday [postpositive]n Monday next
                          (of an event or occasion) occurring directly in time after the present or most recent one, without anything of the same kind intervening:the next election next time I’ll bring a hat

                          2coming immediately after the present one in order, rank, or space:the woman in the next room the next chapter building materials were next in importance

                          adverb

                          on the first or soonest occasion after the present; immediately afterward:wondering what would happen next next, I heard the sound of voices
                          [with superlative] following in the specified order:Joe was the next oldest after Martin

                          noun

                          the next person or thing : one moment he wasn’t there, the next he was the week after next

                          preposition
                          archaic

                          next to:he plodded along next him
                          As we can quite clearly see from both Merriam-Webster and Oxford "Next" is NOT a general future term but a very very specific one. In the context we're speaking of (definition 2 under adjective): the one immediately after the current. Now it is possible to make it refer to a range and even a vague range but that requires more words.
                          I.E. "openSUSE is looks to switch to Btrfs at some point over the next few releases" instead of "openSUSE looks to switch to Btrfs for next release".

                          As a result when we say "the next release of openSUSE" we are only referring to 13.1, and until the release of 13.1 it will never mean 13.2, at which point it will not include 13.3 and so on.

                          Originally posted by GreatEmerald View Post
                          Also note that even with the meaning of being a single one after the current one, 13.2 is the next development version.
                          Do you see anywhere in his article that is indicating he's talking about the next development version? Does the number 13.2 or the term "development version" even come up once? The answer to these is no, infact

                          ftfa:
                          In today's openSUSE 13.1 Beta announcement, it was revealed about making Btrfs "the default on the next openSUSE."
                          In order to promote testing of Btrfs, the openSUSE 13.1 Beta today is encouraging users of new installs to test the file-system over EXT4 by having a "want to test Btrfs?" pop-up dialog during the new installs -- but that will be dropped for the final 13.1 release.
                          OpenSUSE would be looking at shipping Btrfs as the default for the next openSUSE release with enabling only safe file-system options by default [...] as posted in the 13.1 Beta 1 announcement.
                          all of these rather clearly indicate that he's talking about 13.1, and the only line you could potentially even argue in his favour is this one
                          It looks like in 2014 we may finally see Btrfs entering the spotlight as being the production-ready next-generation Linux file-system.
                          Except that 13.1 will be released in late November thus with the understanding that 13.1 would make Btrfs the default would set up for 2014 to be the year it enters the spotlight. Sure you can absolutely argue that it's referring to 13.2 but you can't argue that it could not also be referring to 13.1
                          Last edited by Luke_Wolf; 09-21-2013, 02:11 PM.

                          Comment


                          • #43
                            Originally posted by HeavensRevenge View Post
                            Well, of course it's something I thought they would have avoided but there's countless reports of people saying their BTRFS installations slow to grinding haults ~4 months after installation and simply migrating to EXT4 makes them feel magnitudes faster. Also there was a nice presentation of a dev showing a scatter-plot of disk access times and how BTRFS exponentially degraded over a 22 hour test of hardcore usage and stressing the FS for metadata-intensive workloads.
                            http://opensuse.14.x6.nabble.com/Btr...td4994291.html is a good record of many people confirming this exact problem manifesting and that they did NOT get this right.
                            Btrfs gives you many options as to how to do things. For instance, you CAN store your data and metadata in the same nodes for greater locality/space-efficiency but the docs say you should do this only for small filesystems (under 1G, iirc). If someone used that option, for instance, for a larger fs then that could lead to serious performance issues. My point is that the data from that link wasn't giving us much detail. There are many issues with btrfs that are WELL documented but I'd not look to that thread for them (i.e., we don't know what version of btrfs-progs they used, what option they used for volume creation---that is hugely important).
                            Do you have a link to that dev's data where he was stressing the fs? Was it on the btrfs ml?

                            Of course I have, but always only for testing and I never used it long term beyond 2 weeks or so. You're all bigger men than I am to trust my root to BTRFS that's all I've got to say, and I experiment with some pretty crazy stuff like distcc distributed compiles lol, but no way would I ever trust my data to BTRFS at this moment of it's lifetime.
                            I've used btrfs a few different times (currently I've had it as my root partition for ~one year and haven't had any real issues, iirc. I performed a scrub last night for the first time, and it came back with everything perfect (only took around two minutes). To prevent issues with filling up the disk, I mount it with autodefrag and that seems to give available and free space very similar values.
                            While I don't mind running it on root, I'm not quite to the point where I've trust it with my home data, at least until I get complete backups. Fixing root problems isn't that hard, even if that includes wiping it and imaging from a known good root with a live distro. However, my understanding is that it is quite unusual for btrfs to get to that state (i.e., the tools for recovery at least A root node are quite good).

                            Mason isn't stupid. He's an experienced fs developer so I'd trust him. Obviously there are problems, and I think that the whole filesystem development community should change practices to, as another poster has said in another thread, first, using verification tools to make sure the core ideas of the fs make sense. To THEN move to implementation through a fuse/kernel fs. Something like a fs really needs to be used with tools like alloy, but oss hasn't really embraced such practices yet.

                            Comment


                            • #44
                              Originally posted by liam View Post
                              I think that the whole filesystem development community should change practices to, as another poster has said in another thread, first, using verification tools to make sure the core ideas of the fs make sense. To THEN move to implementation through a fuse/kernel fs. Something like a fs really needs to be used with tools like alloy, but oss hasn't really embraced such practices yet.
                              ZFS already does this. The entire filesystem is compiled for userland and is exercised with a tool called ztest. It is able to rapidly simulate random failures in userland. So far, I am not aware of any other filesystem that does this.

                              Comment


                              • #45
                                Originally posted by ryao View Post
                                ZFS already does this. The entire filesystem is compiled for userland and is exercised with a tool called ztest. It is able to rapidly simulate random failures in userland. So far, I am not aware of any other filesystem that does this.
                                You missed the formal verification part (hence the use of alloy).
                                What you've described provides no such guarantees.

                                Comment

                                Working...
                                X