From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz, "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, 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, 12 Sep 2023 17:20:42 +0800 [thread overview]
Message-ID: <b25f8b8b-8408-e563-e813-18ec58d3b5ca@oracle.com> (raw)
In-Reply-To: <20230911182804.GA20408@twin.jikos.cz>
On 12/09/2023 02:28, David Sterba wrote:
> 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've added Anand's patch
> https://lore.kernel.org/linux-btrfs/de8d71b1b08f2c6ce75e3c45ee801659ecd4dc43.1694164368.git.anand.jain@oracle.com/
> to misc-next that implements subset of your patch, namely extending
> btrfs_scan_one_device() with the 'mounting' parameter. I haven't looked
> if the semantics is the same so I let you take a look.
>
> As there were more comments to V3, please fix that and resend. Thanks.
Guliherme,
Please also add the newly sent patch to the latest misc-next branch:
[PATCH] btrfs: scan forget for no instance of dev
The test case btrfs/254 fails without it.
Thanks.
next prev parent reply other threads:[~2023-09-12 9:21 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-31 0:12 [PATCH V3 0/2] Supporting same fsid mounting through the single-dev compat_ro feature Guilherme G. Piccoli
2023-08-31 0:12 ` [PATCH V3 1/2] btrfs-progs: Add the single-dev feature (to both mkfs/tune) Guilherme G. Piccoli
2023-09-12 9:27 ` Anand Jain
2023-09-13 23:00 ` Guilherme G. Piccoli
2023-09-19 5:15 ` Anand Jain
2023-08-31 0:12 ` [PATCH V3 2/2] btrfs: Introduce the single-dev feature Guilherme G. Piccoli
2023-09-05 16:50 ` David Sterba
2023-09-05 20:23 ` Guilherme G. Piccoli
2023-09-06 9:49 ` Anand Jain
2023-09-07 13:55 ` David Sterba
2023-09-07 15:07 ` Guilherme G. Piccoli
2023-09-07 16:01 ` Anand Jain
2023-09-07 13:56 ` Guilherme G. Piccoli
2023-09-06 16:14 ` Anand Jain
2023-09-07 15:06 ` Guilherme G. Piccoli
2023-09-11 18:28 ` David Sterba
2023-09-11 18:53 ` Guilherme G. Piccoli
2023-09-12 9:20 ` Anand Jain [this message]
2023-09-12 21:26 ` Guilherme G. Piccoli
2023-09-13 0:39 ` Anand Jain
2023-09-13 13:15 ` Guilherme G. Piccoli
2023-09-13 17:32 ` David Sterba
2023-09-13 17:58 ` Guilherme G. Piccoli
2023-09-13 17:24 ` David Sterba
2023-09-13 17:56 ` Guilherme G. Piccoli
2023-09-04 6:36 ` [PATCH V3 0/2] Supporting same fsid mounting through the single-dev compat_ro feature Anand Jain
2023-09-05 1:29 ` Guilherme G. Piccoli
2023-09-05 16:43 ` David Sterba
2023-09-06 14:19 ` Anand Jain
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=b25f8b8b-8408-e563-e813-18ec58d3b5ca@oracle.com \
--to=anand.jain@oracle.com \
--cc=clm@fb.com \
--cc=david@fromorbit.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=gpiccoli@igalia.com \
--cc=johns@valvesoftware.com \
--cc=josef@toxicpanda.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).