[arch-general] BTRFS integration

C Anthony Risinger anthony at extof.me
Sun May 2 20:43:26 CEST 2010


i maintain an unofficial btrfs initcpio hook in AUR:


the hook provides rollback support among other (future) features.
hook is also required for anyone using a multi-device btrfs setup.  i
would like to start/be included in discussion involving btrfs
integration into AIF, and other aspects of Arch.  i think it would be
nice for users to be able to have the option to use the new filesystem
by default-ish, and have the tools needed to work with it.

specifically, it would be really neat to have "rollback" support in a
"rolling" distro.  people would likely be more willing to ride the
edge of the testing repo if they knew they could simply reboot and all
could be well again when things did break.  right now, the rollback
feature provided by the hook is volatile, but this is only an
implementation detail.  what i mean by this is once you rollback, you
CANNOT promote the "rollback" subvolume to be the new "active"
(default) subvolume; you must fix the default subvolume manually and
reboot again.  anything you do in rollback mode will be lost on the
next rollback.  this is something i intend to change, but i need some
input from other developers.

what i propose is to do away with installing the system onto the
default subvolume (like a typical installation); system will be
installed to it's own subvolume (/root/__active).  something like

├── home
│   ├── __active
│   ├── __rollback
│   ├── snap_11-11-1111_11-11-11
│   └── snap_22-22-2222_22-22-22
└── root
    ├── __active
    ├── __rollback
    ├── snap_11-11-1111_11-11-11
    └── snap_22-22-2222_22-22-22

this is the "subroot" structure; underneath your / [root]. "." is the
original default subvolume.  /root/__active is your "primary"
(default) system. /root/ __rollback is a volatile copy of a
/root/snap_XX (you boot into this [__rollback] when you "rollback").
since snap_XX gets copied to __rollback... if you decide you want to
ditch your changes to __active (since it's messed up anyways), you
just replace __active with __rollback (delete/rename), reboot, and
voilà! your system's __active subvolume works again, and none of your
snapshots got messed with.

same logic for /home/__active and /home/__rollback (and snap_XX)
except you wouldn't have to reboot... maybe we can create login
manager ([xkg]dm) hooks to remount your home folder with a "rollback"
on the next logout or something?  who knows.

we could take a snapshot after install (on the very first boot),
called "__original" or something, then users would always have a copy
of their system immediately after installation; they could
revert/use/delete that if they wanted to at any time.

however, this setup would require mounting the default subvolume
somewhere else in order to gain access to the "subroot" structure, but
it would guarantee that you could not destroy your system no matter
what you did to your / [root].

any ideas on this?  my attempts to generate interest in the forums are
falling on deaf ears so i thought i'd try my luck here.

C Anthony

More information about the arch-general mailing list