On 7/22/20 2:21 AM, Nicholas D Steeves wrote:
Hi,
Reply follows inline.
Goffredo Baroncelli <kreijack@xxxxxxxxx> writes:
Hi all,
this is an RFC to discuss a my idea to allow a simple rollback of the
root filesystem at boot time.
The problem that I want to solve is the following: DPKG is very slow on
a BTRFS filesystem. The reason is that DPKG massively uses
sync()/fsync() to guarantee that the filesystem is always coherent even
in case of sudden shutdown.
The same can be useful even to the RPM Linux based distribution (which however
suffer less than DPKG).
A way to avoid the sync()/fsync() calls without loosing the DPKG
guarantees, is:
1) perform a snapshot of the root filesystem (the rollback one)
2) upgrade the filesystem without using sync/fsync
3) final (global) sync
4) destroy the rollback snapshot
If an unclean shutdown happens between 1) and 4), two subvolume exists:
the 'main' one and the 'rollback' one (which is the snapshot before the
update). In this case the system at boot time should mount the "rollback"
subvolume instead of the "main" one. Otherwise in case of a "clean" boot, the
"rollback" subvolume doesn't exist and only the "main" one can be
mounted.
In [1] I discussed a way to implement the steps 1 to 4. (ok, I missed
the point 3) ).
The part that was missed until now, is an automatic way to mount the rollback
subvolume at boot time when it is present.
My idea is to allow more 'subvol=' option. In this case BTRFS tries all the
passed subvolumes until the first succeed. So invoking the kernel as:
linux root=UUID=xxxx rootflags=subvol=rollback,subvol=main ro
First, the kernel tries to mount the 'rollback' subvolume. If the rollback
subvolume doesn't exist then it mounts the 'main' subvolume.
Of course after the mount, the system should perform a cleanup of the
subvolumes: i.e. if a rollback subvolume exists, the system should destroy
the "main" one (which contains garbage) and rename "rollback" to "main".
To be more precise:
I like the idea of defaulting to a known-good snapshot on unclean
shutdown :-)
Is anyone on this list aware of grub-btrfs
https://github.com/Antynea/grub-btrfs ? It's not my project, by the
way, but I'm curious what advantages your method has compared to the
alleged ZFS-like Boot Environment support of grub-btrfs?
Looking at the script, it seems that grub-btrfs updated the grub.cfg when a new snapshot is created (using the systemd capability to trigger an event in case a certain filesystem change happens).
It is a nice idea, however it requires to regenerate grub.cfg at every snapshot. I think that it increases the likelihood of having a corrupted grub.cfg in case of unclean shutdown.
However, I think that grub definitely has the capability to boot from a rollback subvolume. However, this means that grub is needed to rollback the system, which is an too strong requirement.
Update:
Looking at this answer [https://unix.stackexchange.com/questions/415049/generating-menuentry-for-iso-images-dynamically-in-grub-cfg] it seems that grub has the capability to generate dynamically a menu on the basis of the directory structure
In particular,
I wonder if the problem have already been solved solved due to that
project's snapper support, and if it just needs more exposure, general
testing, and integration for other distributions.
Oh, and to get apt to trigger snapshot creation:
https://github.com/stefxh/apt-btrfs-snapper
Iirc there are a couple other apt-btrfs snapshot creation projects
Best,
Nicholas
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
