Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 54

Thread: OpenSUSE Looks To Switch To Btrfs For Next Release

  1. #31
    Join Date
    Sep 2012
    Posts
    343

    Default

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

  2. #32
    Join Date
    Sep 2012
    Posts
    680

    Default

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

  3. #33
    Join Date
    Sep 2012
    Posts
    343

    Default

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

  4. #34
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,552

    Default

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

  5. #35

    Default

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

  6. #36
    Join Date
    Jun 2011
    Posts
    927

    Default

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

  7. #37
    Join Date
    Jun 2013
    Location
    Canada
    Posts
    30

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

  8. #38
    Join Date
    Jul 2013
    Location
    USA
    Posts
    715

    Default

    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

  9. #39
    Join Date
    Jan 2009
    Posts
    1,403

    Default

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

  10. #40
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,552

    Default

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

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •