jm + btrfs   3

Revisiting How We Put Together Linux Systems
Building a running OS out of layered btrfs filesystems. This sounds awesome.
Instantiating a new system or OS container (which is exactly the same in this scheme) just consists of creating a new appropriately named root sub-volume. Completely naturally you can share one vendor OS copy in one specific version with a multitude of container instances.

Everything is double-buffered (or actually, n-fold-buffered), because usr, runtime, framework, app sub-volumes can exist in multiple versions. Of course, by default the execution logic should always pick the newest release of each sub-volume, but it is up to the user keep multiple versions around, and possibly execute older versions, if he desires to do so. In fact, like on ChromeOS this could even be handled automatically: if a system fails to boot with a newer snapshot, the boot loader can automatically revert back to an older version of the OS.

(via Tony Finch)
via:fanf  linux  docker  btrfs  filesystems  unionfs  copy-on-write  os  hacking  unix 
september 2014 by jm
A short history of btrfs []
wow, sounds good! looking forward to this hitting production-ready status
btrfs  history  zfs  linux  open-source  licensing  storage  sysadmin  b-trees  b+trees  algorithms  fs  filesystems 
august 2009 by jm

Copy this bookmark: