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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.