On Nov 7, 2013, at 4:45 PM, Michael Göhler <visit@xxxxxxx> wrote: > The boot subvolume is then set with 'btrfs subvolume set-default' and mounted without subvol/subvolid option by Arch's default mount handler. I'm unconvinced it's a good idea for it to be used behind the scenes for the described purpose. Consider the following: 1. btrfs subvolume set-default uses a user space tool and in my view it's primarily a user domain behavior modifier for the mount command. 2. It makes the actual mounted subvolume obscured, cat /proc/self/mountinfo doesn't show what subvolume is mounted unless subvol= is explicitly used in /etc/fstab. 3. Grub2 (and I'm pretty sure grubby) do not use the set-default. The GRUB intent for the prefix to search an absolute path, not one relative to the default subvolume. There's a bug that should very recently (week) be fixed, where GRUB fails to find prefix if set-default is changed. This maybe isn't affecting the particular layout you describe where only rootfs is on btrfs, rather than /boot being on its own subvolume. > That way, we ensure the best compatibility and lowest maintenance, as we don't overwrite default init functions. I'm sympathetic to the alternative problem, which is that you need to alter grub.cfg to use the proper rootflags=subvol= to explicitly use the proper snapshot, and also it would mean altering the /etc/fstab within that snapshot. > > 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. The fact of the matter is, we don't have the necessary metadata support in btrfs to understand the relationships between snapshots/subvolumes. There is a need for this, not least of which is the use case you're describing. This has come up with Fedora also for their offline updates rollback they want to eventually do. And it's also an issue with distribution installers which see these snapshots as wholly unique instances of existing installations, rather than as related snapshots. > > 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? Well and it raises the problem of nested subvolumes making the parent subvolume undeletable. So I'd question the significant benefit of making nested subvolume in particular /var. It's complicating how the OS is to be put back together again. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
