[hacktree] README: Some notes on BTRFS
- From: Colin Walters <walters src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [hacktree] README: Some notes on BTRFS
- Date: Mon, 17 Oct 2011 15:09:01 +0000 (UTC)
commit aaae116f8e60b3c563c8f6b8b1616ceb938517ce
Author: Colin Walters <walters verbum org>
Date: Mon Oct 17 11:08:25 2011 -0400
README: Some notes on BTRFS
README.md | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
---
diff --git a/README.md b/README.md
index 4dcbfac..ca6eb5b 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]