linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).