Re: booting btrfs

[Chris Murphy]

On Dec 23, 2013, at 7:26 PM, Michael Chang <address@hidden> wrote:

> Now I tend to agree that supporting config for snapshot booting
> shouldn't be upstream's consideration due to it's compliexity and
> dependency to system, Despite on this, I still like to ask : Did
> upstream think about any patch trying to provide relative path support
> for btrfs subvolume name or id's a worthy work or not?

My vague recollection is that it did used to work this way before 2.00, but 
maybe was unintended?

> Thanks.  It can be a solution for some use cases but for the one I
> want to achieve it's insufficent. What I'm looking for is to list the
> available snapshots in the boot menu for selecting and then booting to
> it.

OK in that case the tool creates the snapshots, modifies its fstab, and updates 
grub.cfg so they're displayed.

Direct editing of grub.cfg is fragile in that the user could run grub-mkconfig 
at any time. It's better for the tool to use an existing entry as a template, 
and add snapshot entries to 40_custom, then run grub-mkconfig. 

Another thing to note is that there are UEFI computers shipping that don't have 
USB initialized by the firmware by default at boot time. So the user couldn't 
use this menu on such systems - which some have suggested will become 
increasingly common. This implies a snapshot tool that provides the UI to 
choose snapshots prior to rebooting into that snapshot.

> Meanwhile the snapshot is not for os installation,
> people occasionally want to boot into it for special reasons like he
> want to find from when his system performance start downgrading. I'd
> consider such multiboot should not consider os installtion be in
> snapshots .. because it makes no sense.

I understand. I mean it's eventually feasible for a single Btrfs volume to 
contain multiple distributions in their own subvolumes, because Btrfs volumes 
are designed to be large, and easily extend to multiple devices.

It's essentially the same as multiboot without Btrfs at all, the core.img would 
point to a stable "master" grub.cfg that in turn uses configfile to point to 
the grub.cfg for each distribution. Each distribution maintains its own 
grub.cfg without modifying the "master" that core.img is pointing to. It would 
be nice if distributions made this configuration easy for users to implement.

I think this might be better than doing it with set-default and leave that 
strictly a user domain function/short cut to being able to mount without -o 
subvol= option.

> 
>> 
>> I think the idea of snapshots in the domain of a boot manager/boot loader is 
>> really overly complicated. For another thing, it's not really appropriate to 
>> do a rollback and then immediately start modifying it by booting from it. 
>> What you'd want to do is snapshot the rollback, and then use that "cloned" 
>> copy of the rollback, leaving the original rollback in place. Otherwise the 
>> provenance of that <inserttime> snapshot is obliterated.
> 
> I think that's like seed device and yes there should have such
> handling in initrd to use a clone copy of read-only snapshots when
> your kernel parameters are asking to mount it as /.

Yes good point. Your snapshot tool could first create a read only snapshot, 
then for no space cost also create a rw snapshot of the read only one, then add 
the rw snapshot to the grub.cfg. The tool could give the user the option to 
always "revert" the changes caused by booting a snapshot - this would cause the 
rw snapshot being deleted and a new rw snapshot created from the read only one.


Chris Murphy