[arch-general] BTRFS integration

[C Anthony Risinger]

On Mon, May 3, 2010 at 3:46 PM, Dieter Plaetinck <dieter at plaetinck.be> wrote:
>
> I was the one who proposed aif --expert on the forums  ;)

heh yeah, i was too lazy too look it up, and it was all a part of my
secret plan to get you to back me up :)

> Did I understand it correctly that you can fix the "cannot promote a
> snapshot to become the default subvolume" problem by just using a
> specific named subvolume instead of the default? i.e. it's basically
> just a name change, nothing drastic?

there isn't really a problem here, i just haven't built it into the
hook yet.  what i (we) really need is to decide on an appropriate
"subroot" structure. basically, i don't think we should install the
system into the default, "." (the original default subvolume is a
period), subvolume.  if we do this it makes it messier to move
root/home/var/whatever snapshots around.  we should reserve the "."
subvolume for our implementation specifics, and install the system
into say /root/__active as i suggested before.

more reasons for the above is that subvolumes behave like folders and
are nestable, and you cant remove a subvolume that has another inside
it. the nested one must be moved outside the parent, or removed first.
 my goal was to have all snapshots "under" or "outside" the root, so
the user cannot see or mess with them, and snapshots are clean and
leave no artifacts (like empty folders where nested subvolumes used to
be [snapshots are not recursive]).  all of this i have gathered from
practice.

subvolumes can be mounted two ways via a mount option:

1) subvol=<subvolume_name>
2) subvol=<subvolume_id>

1 can only be used if the subvolume is in the root of the FS, i.e.
/__active would work, but /root/__active would NOT... the mount option
cannot have slashes and i don't know if this will change.  2 can be
used to mount ANY existing subvolume, but you must know it's internal
id, and the tools for this are only available in 2.6.34+ via the
command "btrfs subvolume list"

there is also the option in 2.6.34+ to use the command "btrfs
subvolume set-default" to make any subvolume the new default (via it's
internal id not its [folder] name), and then the mount option [subvol]
is not needed.

we have a couple options that are basically the same except for implementation:

1) use a naming scheme and keep the __active (default) subvolume in the root
in this setup, "promotion" of any snapshot to default simply means
removing the old /__active, and snapshotting the target subvolume (say
/__rollback) to /__active.  this would require "subvol=__active" to be
added to the rootflags at EVERY boot, and __active MUST reside in the
root (since we are booting it by name and not id).  this option has
the advantage of working with older kernels and versions of btrfs that
lack the ability to define a new default or mount by id, but is less
flexible.

2) use a naming scheme and use setting defaults and ids for booting
this is basically the same result as above, but we can put __active
[and others] wherever we want, like /root/__active.  we would then
boot it via it's internal id (using rootflags/mount options) or by
declaring __active the new default.  depends on a 2.6.34+ kernel, but
its more flexible in how we lay out the "subroot".

both depend on mounting the "." subvolume somewhere after the fact
(via fstab/inside initcpio hook) for
listing/snapshotting/moving/renaming operations.

bleh, apologies for the length, trying to be thorough.

> About the implementation in aif, it's doable.
> after all, i managed to implement LVM, which is kinda similar (you can
> put PV's on partitions/devices, use multiple PV's in one VG, put
> multiple LV's in 1 VG, and then make normal filesystems (and define
> mountpoints) on single LV's).

i will have to take a closer look then.  i have never setup or used
LVM before; but that all sounds pretty similar; if anything it should
be simpler/cleaner/faster in BTRFS?  we'll see.

> About the "creating snapshots immediately after performing an
> installation" idea:
> seems like an interesting feature, which could happen at the end of the
> installation process (no reboot needed)

that would work too, and it would be just as easy to build it into the
[initcpio] hook.  users could clone this snapshot and setup totally
different systems, switchable at boot time (if one wished).

my goal was just to get the ball rolling on this, and generate some
interest and brainstorm use cases. with some direction i can update
the mkinitcpio-btrfs hook to whatever standards for a future merge
into the core repositories.  this could be updated in conjunction with
AIF.  my next updates to the hook were going to introduce an
/etc/btrfs.conf file (to be included into the initcpio image), and
this config file would control the various operations of the hook.
however, i'm not sure what all the rules are here...

with great power [and flexibility] comes great responsibility.

C Anthony