From: Josef Bacik <josef@toxicpanda.com>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: linux-btrfs@vger.kernel.org, clm@fb.com, dsterba@suse.com,
linux-fsdevel@vger.kernel.org, kernel@gpiccoli.net,
kernel-dev@igalia.com, anand.jain@oracle.com,
david@fromorbit.com, kreijack@libero.it, johns@valvesoftware.com,
ludovico.denittis@collabora.com, quwenruo.btrfs@gmx.com,
wqu@suse.com, vivek@collabora.com
Subject: Re: [PATCH 3/3] btrfs: Add parameter to force devices behave as single-dev ones
Date: Thu, 17 Aug 2023 11:44:41 -0400 [thread overview]
Message-ID: <20230817154441.GC2934386@perftesting> (raw)
In-Reply-To: <20230803154453.1488248-4-gpiccoli@igalia.com>
On Thu, Aug 03, 2023 at 12:43:41PM -0300, Guilherme G. Piccoli wrote:
> Devices with the single-dev feature enabled in their superblock are
> allowed to be mounted regardless of their fsid being already present
> in the system - the goal of such feature is to have the device in a
> single mode with no advanced features, like RAID; it is a compat_ro
> feature present since kernel v6.5.
>
> The thing is that such feature comes in the form of a superblock flag,
> so devices that doesn't have it set, can't use the feature of course.
> The Steam Deck console aims to have block-based updates in its
> RO rootfs, and given its A/B partition nature, both block devices are
> required to be the same for their hash to match, so it's not possible
> to compare two images if one has this feature set in the superblock,
> while the other has not. So if we end-up having two old images, we
> couldn't make use of the single-dev feature to mount both at same time,
> or if we set the flag in one of them to enable the feature, we break
> the block-based hash comparison.
>
> We propose here a module parameter approach to allow forcing any given
> path (to a device holding a btrfs filesystem) behaving as a single-dev
> device. That would useful for cases like the Steam Deck one, or for
> debug purposes. If the filesystem already has the compat_ro flag set
> in its superblock, the parameter is no-op.
>
Now this one I'm not a fan of. For old file systems you can simply btrfstune
them to have your new flag. Is there a reason why that wouldn't be an option?
If it is indeed required, which is a huge if, I'd rather this be accomplished a
mount option. I have a strong dislike for new mount options, but I think that's
a cleaner way to accomplish this than a module option. Thanks,
Josef
next prev parent reply other threads:[~2023-08-17 15:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-03 15:43 [PATCH V2 0/3] Supporting same fsid mounting through a compat_ro feature Guilherme G. Piccoli
2023-08-03 15:43 ` [PATCH 1/3] btrfs-progs: Add the single-dev feature (to both mkfs/tune) Guilherme G. Piccoli
2023-08-17 15:46 ` Josef Bacik
2023-08-17 16:16 ` Guilherme G. Piccoli
2023-08-03 15:43 ` [PATCH 2/3] btrfs: Introduce the single-dev feature Guilherme G. Piccoli
2023-08-04 8:27 ` Qu Wenruo
2023-08-04 11:38 ` Guilherme G. Piccoli
2023-08-17 15:41 ` Josef Bacik
2023-08-17 16:20 ` Guilherme G. Piccoli
2023-08-17 16:58 ` Josef Bacik
2023-08-17 17:09 ` Guilherme G. Piccoli
2023-08-23 16:31 ` Anand Jain
2023-08-24 20:55 ` Guilherme G. Piccoli
2023-08-29 20:28 ` Guilherme G. Piccoli
2023-08-30 7:11 ` Anand Jain
2023-08-30 12:00 ` Guilherme G. Piccoli
2023-08-03 15:43 ` [PATCH 3/3] btrfs: Add parameter to force devices behave as single-dev ones Guilherme G. Piccoli
2023-08-17 15:44 ` Josef Bacik [this message]
2023-08-20 18:16 ` Guilherme G. Piccoli
2023-08-17 13:56 ` [PATCH V2 0/3] Supporting same fsid mounting through a compat_ro feature Guilherme G. Piccoli
2023-08-17 14:19 ` Josef Bacik
2023-08-17 14:23 ` Guilherme G. Piccoli
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=20230817154441.GC2934386@perftesting \
--to=josef@toxicpanda.com \
--cc=anand.jain@oracle.com \
--cc=clm@fb.com \
--cc=david@fromorbit.com \
--cc=dsterba@suse.com \
--cc=gpiccoli@igalia.com \
--cc=johns@valvesoftware.com \
--cc=kernel-dev@igalia.com \
--cc=kernel@gpiccoli.net \
--cc=kreijack@libero.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ludovico.denittis@collabora.com \
--cc=quwenruo.btrfs@gmx.com \
--cc=vivek@collabora.com \
--cc=wqu@suse.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;
as well as URLs for NNTP newsgroup(s).