From: Nicholas D Steeves <nsteeves@gmail.com>
To: Goffredo Baroncelli <kreijack@libero.it>, linux-btrfs@vger.kernel.org
Subject: Re: [RFC] btrfs: strategy to perform a rollback at boot time
Date: Tue, 21 Jul 2020 20:21:39 -0400 [thread overview]
Message-ID: <87imegh018.fsf@DigitalMercury.dynalias.net> (raw)
In-Reply-To: <20200721203340.275921-1-kreijack@libero.it>
[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]
Hi,
Reply follows inline.
Goffredo Baroncelli <kreijack@libero.it> 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? 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2020-07-22 0:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-21 20:33 [RFC] btrfs: strategy to perform a rollback at boot time Goffredo Baroncelli
2020-07-21 20:33 ` [PATCH] btrfs: allow more subvol= option Goffredo Baroncelli
2020-07-21 20:50 ` Steven Davies
2020-07-22 1:12 ` kernel test robot
2020-07-21 20:55 ` [RFC] btrfs: strategy to perform a rollback at boot time Steven Davies
2020-07-23 19:52 ` Goffredo Baroncelli
2020-07-21 21:09 ` Chris Murphy
2020-07-22 0:21 ` Nicholas D Steeves [this message]
2020-07-23 20:02 ` Goffredo Baroncelli
2020-07-23 21:53 ` Zygo Blaxell
2020-07-24 11:56 ` Goffredo Baroncelli
2020-07-24 22:08 ` Chris Murphy
2020-07-25 2:37 ` Zygo Blaxell
2020-07-27 12:26 ` David Sterba
2020-07-27 17:25 ` Goffredo Baroncelli
2020-07-27 17:34 ` Goffredo Baroncelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87imegh018.fsf@DigitalMercury.dynalias.net \
--to=nsteeves@gmail.com \
--cc=kreijack@libero.it \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox