Re: [RFC] btrfs: strategy to perform a rollback at boot time

[Goffredo Baroncelli <kreijack@inwind.it>]

On 7/27/20 2:26 PM, David Sterba wrote:
> On Fri, Jul 24, 2020 at 01:56:58PM +0200, Goffredo Baroncelli wrote:
>>> This could be done already from the initramfs.
>>
>> Ok, this means that we have three possibility:
>> 1) do this at bootloder level (eg grub)
>> 2) do this at initramfs
>> 3) do this at kernel level (see my patch)
>>
>> All these possibilities are a viable solution. However I find 1) and
>> 2) the more "intrusive", and distro specific. My fear is that each
>> distro will take a different choice, leading to a more fragmentation.
>> I hoped that the solution nr 3, could help to find a unique solution....
> 
> IMO bootloader or initrd are the right places to do the mount test and
> eventual rollback. What kernel provides is to mount the subvolume, it's
> up the the user to supply the right one. When I read the proposal the
> option 2 was the the first thought that can be implemented with the
> existing kernel support already.
> 
> Distros take different approach to various problems, and this is fine.
> Here the list of fallback subvolumes, naming, where it's stored or
> whatever may differ and the kernel provides the base functionality.
> 
> It would make sense to push that down one level in case all distros have
> to repeat the same code and there would be an established way to do the
> main/rollback switch.

I am looking for another solution, which is based on some suggestions taken
from Zygo and Chris. This solution requires no change to initrd, kernel and bootloader.

More or less the sequence is the following:

During the upgrade
==================
1 cleanup previous unclean subvolume and snapshot pairs (due to an unattended abort)
2 take a snapshot of the main subvolume
3 swap (atomically via renameat2) the original subvolume and its snapshot
	this means that in case of an unattended reboot, the system starts
	from the snapshot
4 update the filesystem
5 re-swap original subvolume and its snapshot
6 delete the snapshot (or collect it to provide a way to return to previous configuration)

This procedure has three possible endings:
1) all ok, nothing to do
2) unattended reboot happened; at startup a cleanup of the subvolume is required
3) unattended abort happened without a reboot; we still have the two subvolumes, at least
during the shutdown the subvolume and its snapshot have to be swapped (if required)

During the startup
==================
A script checks if the system started from the snapshot, and if so
delete the original subvolume (or collect it to provide an history)


During the shutdown
===================
a script checks if both the subvolume and its snapshot are present.
This happens if the upgrade procedure abort for some reasons (but the system doesn't reboot).
In this case I think that it is safe to swap snapshot and original subvolume and
drop the snapshot (or collect it to provide....)


> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5