From: David Sterba <dsterba@suse.cz>
To: kreijack@inwind.it
Cc: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
linux-btrfs@vger.kernel.org,
Chris Murphy <lists@colorremedies.com>
Subject: Re: [RFC] btrfs: strategy to perform a rollback at boot time
Date: Mon, 27 Jul 2020 14:26:47 +0200 [thread overview]
Message-ID: <20200727122647.GK3703@twin.jikos.cz> (raw)
In-Reply-To: <a4074100-b006-7d64-e22d-779ad15191c0@libero.it>
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.
next prev parent reply other threads:[~2020-07-27 12:27 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
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 [this message]
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=20200727122647.GK3703@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=ce3g8jdj@umail.furryterror.org \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
/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