Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Steven Davies <btrfs-list@steev.me.uk>
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 21:55:07 +0100	[thread overview]
Message-ID: <1e058a3e-a563-152b-b6df-57fa18b13df8@steev.me.uk> (raw)
In-Reply-To: <20200721203340.275921-1-kreijack@libero.it>

On 21/07/2020 21:33, Goffredo Baroncelli wrote:
> 
> 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:
> 
> 	if test -d "rollback"; then
> 		if test -d "old"; then
> 			btrfs sub del "old"
> 		fi
> 		if test -d "main"; then
> 			mv "main" "old"
> 		fi
> 		mv "rollback" "main"
> 		btrfs sub del "old"
> 	fi
> 
> Comments are welcome

I like this idea. Do we have an easy way of detecting which subvolume 
has been mounted (through sysfs or similar), or would you expect to 
always be testing this based on the existence of certain 
subvolumes/directories?

-- 
Steven Davies

  parent reply	other threads:[~2020-07-21 20:55 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 ` Steven Davies [this message]
2020-07-23 19:52   ` [RFC] btrfs: strategy to perform a rollback at boot time Goffredo Baroncelli
2020-07-21 21:09 ` Chris Murphy
2020-07-22  0:21 ` Nicholas D Steeves
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=1e058a3e-a563-152b-b6df-57fa18b13df8@steev.me.uk \
    --to=btrfs-list@steev.me.uk \
    --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