summaryrefslogtreecommitdiff
path: root/README.md
diff options
context:
space:
mode:
authorColin Walters <walters@verbum.org>2011-10-17 11:08:25 -0400
committerColin Walters <walters@verbum.org>2011-10-17 11:08:25 -0400
commitaaae116f8e60b3c563c8f6b8b1616ceb938517ce (patch)
tree35a643a63e7bdb856c01619d1dba60b37043ec49 /README.md
parent8020f444cf7bbc936be9e45670401e641e297d36 (diff)
downloadostree-aaae116f8e60b3c563c8f6b8b1616ceb938517ce.tar.gz
README: Some notes on BTRFS
Diffstat (limited to 'README.md')
-rw-r--r--README.md35
1 files changed, 35 insertions, 0 deletions
diff --git a/README.md b/README.md
index 4dcbfac2..ca6eb5b2 100644
--- a/README.md
+++ b/README.md
@@ -325,6 +325,37 @@ harder would be maintaining binary compatibilty with any arbitrary
Note these RPMs act like local configuration - they would be
reinstalled every time you switch roots.
+What about BTRFS? Doesn't it solve everything?
+-----------------------------------------------
+
+In short, BTRFS is not a magic bullet, but yes - it helps
+significantly. The obvious thing to do is layer BTRFS under dpkg/rpm,
+and have a separate subvolume for /home so rollbacks don't lose your
+data. See e.g.
+<http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs>
+
+As a general rule an issue with the BTRFS is that it can't roll back
+just changes to things installed by RPM (i.e. what's in rpm -qal).
+
+For example, it's possible to e.g. run yum update, then edit something
+in /etc, reboot and notice things are broken, then roll back and have
+silently lost your changes to /etc.
+
+Another example is adding a new binary in /usr/local. You could say,
+"OK, we'll use subvolumes for those!". But then what about /var (and
+your VM images that live in /var/lib/libvirt ?)
+
+Finally, probably the biggest disadvantage of the rpm/dpkg + BTRFS
+approach is it doesn't solve the race conditions that happen when
+unpacking packages into the live system. This problem is really
+important to me.
+
+Note though hacktree can definitely take advantage of BTRFS features!
+In particular, we could use "reflink"
+<http://lwn.net/Articles/331808/> instead of hard links, and avoid
+having the object store corrupted if somehow the files are modified
+directly.
+
Other systems
-------------
@@ -355,6 +386,10 @@ didn't use them:
bad, but hacktree is better than it for the exact same reasons git
is better than Subversion.
+ - BTRFS: <http://en.wikipedia.org/wiki/Btrfs>
+
+ See above.
+
- Jhbuild: <https://live.gnome.org/Jhbuild>
What we've been using in GNOME, and has the essential property of allowing you