Announcement

Collapse
No announcement yet.

How SUSE Linux Makes Use Of Btrfs Rollbacks

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

  • How SUSE Linux Makes Use Of Btrfs Rollbacks

    Phoronix: How SUSE Linux Makes Use Of Btrfs Rollbacks

    Besides Oracle Linux, OpenSUSE and SUSE Linux Enterprise Server were among the first tier-one Linux distributions really backing the Btrfs file-system. SUSE has liked Btrfs for years and at last week's LinuxCon Europe 2015 in Dublin there was a presentation on their use of Btrfs with handling system rollbacks...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2

    Thanks, now i'm a criminal because you didn't warn about the disclaimer in the last page of the pdf. Really nicely done!

    Comment


    • #3
      Originally posted by arabek View Post
      Thanks, now i'm a criminal because you didn't warn about the disclaimer in the last page of the pdf. Really nicely done!
      thanks, now i'm a criminal because of your comment. as much as i had no interest originally, your comment made me want to check the disclaimer

      and for more information if anyone is wondering the same as i was. disclaimer says this is internal Suse document not to be shared publicly

      Comment


      • #4
        Originally posted by justmy2cents View Post

        thanks, now i'm a criminal because of your comment. as much as i had no interest originally, your comment made me want to check the disclaimer

        and for more information if anyone is wondering the same as i was. disclaimer says this is internal Suse document not to be shared publicly
        Strange, that the disclaimer is at the END of the document

        Comment


        • #5
          Originally posted by arabek View Post

          Strange, that the disclaimer is at the END of the document
          lol, yet another criminal added to the list next one will probably check spelling and grammar

          Comment


          • #6
            Worry not, you're only a criminal if you shared it publicly--if you only looked at it, you're just an accomplice.
            Edit: or if you saved a copy to your computer, since they own the copyright.

            Comment


            • #7
              So basically Nix at the filesystem level?

              Comment


              • #8
                Originally posted by CrystalGamma View Post
                So basically Nix at the filesystem level?
                Just some handy snapshots. Like you do it in VMs, etc but at filesystem level rather than at block device level. So you can get some hierarchy frozen in time and quickly go back to past if desired. In fact you can even have several "instances" of same hierarchy at once, both read-only or even writeable. Readonly snapshots are frozen in time. Writeable snapshots can have their alternate "history" and end up in different state than other instances of same hierarchy.

                As long as files in snapshots have identical parts they will share underlying blocks. When something changes, only changed blocks would be written somewhere (that's CoW idea, after all). So you can access several instances of same hierarchy and it wouldn't be as heavy as storing whole independent copies of hierarchy.

                I.e. while you can access snapshot like a separate subtree, and it would live by its own life, this subtree is almost instantly created (its a matter of extra reference to already existing blocks) and basically just a reference to its predecessor unless you change somthing. Then, changed blocks are no longer referenced to predecessor and stored separately. And unless you have grown too many differences between snapshots, you can have 5 independent snapshots in independent subtrees, acting like 5 different hierarchies ... while taking only a bit more space than 1 hierarchy would do. Because most blocks are shared unless they are different.

                This is convenient and gives you a "multiverse". And allows to fiddle with hierarchy history in quick and versatile ways. As one of uses, you can snapshot system before updating packages and if something goes nuts, you can just assume upgrade never happened by assigning that snapshot as default view of hierarchy. So system would go older state really quickly. Though one have to understand it rolls back ALL changes.

                Comment

                Working...
                X