Re: [PATCH V3 2/2] btrfs: Introduce the single-dev feature

From: David Sterba <dsterba@suse.cz>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: linux-btrfs@vger.kernel.org, clm@fb.com, josef@toxicpanda.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 V3 2/2] btrfs: Introduce the single-dev feature
Date: Tue, 5 Sep 2023 18:50:41 +0200	[thread overview]
Message-ID: <20230905165041.GF14420@twin.jikos.cz> (raw)
In-Reply-To: <20230831001544.3379273-3-gpiccoli@igalia.com>

On Wed, Aug 30, 2023 at 09:12:34PM -0300, Guilherme G. Piccoli wrote:
> Btrfs doesn't currently support to mount 2 different devices holding the
> same filesystem - the fsid is exposed as a unique identifier by the
> driver. This case is supported though in some other common filesystems,
> like ext4.
> 
> Supporting the same-fsid mounts has the advantage of allowing btrfs to
> be used in A/B partitioned devices, like mobile phones or the Steam Deck
> for example. Without this support, it's not safe for users to keep the
> same "image version" in both A and B partitions, a setup that is quite
> common for development, for example. Also, as a big bonus, it allows fs
> integrity check based on block devices for RO devices (whereas currently
> it is required that both have different fsid, breaking the block device
> hash comparison).
> 
> Such same-fsid mounting is hereby added through the usage of the
> filesystem feature "single-dev" - when such feature is used, btrfs
> generates a random fsid for the filesystem and leverages the long-term
> present metadata_uuid infrastructure to enable the usage of this
> secondary virtual fsid, effectively requiring few non-invasive changes
> to the code and no new potential corner cases.
> 
> In order to prevent more code complexity and corner cases, given
> the nature of this mechanism (single devices), the single-dev feature
> is not allowed when the metadata_uuid flag is already present on the
> fs, or if the device is on fsid-change state. Device removal/replace
> is also disabled for devices presenting the single-dev feature.
> 
> Suggested-by: John Schoenick <johns@valvesoftware.com>
> Suggested-by: Qu Wenruo <wqu@suse.com>
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>

I'd like to pick this as a feature for 6.7, it's extending code we
already have for metadata_uuid so this is a low risk feature. The only
problem I see for now is the name, using the word 'single'.

We have single as a block group profile name and a filesystem can exist
on a single device too, this is would be confusing when referring to it.
Single-dev can be a working name but for a final release we should
really try to pick something more unique. I don't have a suggestion for
now.

The plan for now is that I'll add the patch to a topic branch and add it
to for-next so it could be tested but there might be some updates still
needed. Either as changes to this patch or as separate patches, that
depends.