Hi,
I'm a contributor of the Arch Linux package mkinitcpio-btrfs [1]. The
goal of this hook is to provide Btrfs rollback support for root
filesystems directly from initrd.
Technically we are using a subvolume to store the root filesystem. The
user can snapshot it entirely and boot from this snapshot. In case of
rollback our hook snapshots the snapshot again, to keep its original
unchanged. The boot subvolume is then set with 'btrfs subvolume
set-default' and mounted without subvol/subvolid option by Arch's
default mount handler. That way, we ensure the best compatibility and
lowest maintenance, as we don't overwrite default init functions.
Assuming we have the following setup:
# btrfs su li -p /
ID 256 gen 86 parent 5 top level 5 path root
ID 259 gen 86 parent 256 top level 256 path var
ID 260 gen 86 parent 256 top level 256 path usr
The use case for that is to set quotas for the child subvolumes.
Now, if we snapshots the root subvolume, the child subvolumes are not
snapshoted with it. There is no back reference which would allow Btrfs
to auto-mount the original child subvolumes when we mount the snapshot
as new root filesystem. Of cause we could snapshot the childs separately
into their desired directories. But this would not help, because our
hook snapshots the snapshot again, to keep it's original untouched while
rolling back. And we don't have fstab to find out the correct mount
points at this early boot stage.
Atm. all scenarios results in /usr/bin/init not found.
So here comes my question:
Wouldn't it be helpful to add a --recursive option to 'btrfs subvolume
snapshot' to snapshot child subvolumes together with their parent?
Or maybe it is possible to add some functionality to reference the child
subvolumes on the snapshots fs-tree to allow auto-mounting?
I appreciate other ideas or opinions too.
Thanks,
Michael
[1] https://aur.archlinux.org/packages/mkinitcpio-btrfs/
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
