How SUSE Linux Makes Use Of Btrfs Rollbacks

[phoronix]

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

http://www.phoronix.com/scan.php?pag...trfs-Rollbacks

[arabek]

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

[justmy2cents]

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

[arabek]

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

[justmy2cents]

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

[Nobu]

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.

[CrystalGamma]

So basically Nix at the filesystem level?

[SystemCrasher]

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.