From: "André Almeida" <andrealmeid@igalia.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>,
Jeff Layton <jlayton@kernel.org>, NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
Carlos Maiolino <cem@kernel.org>,
Amir Goldstein <amir73il@gmail.com>, Chris Mason <clm@fb.com>,
David Sterba <dsterba@suse.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org, linux-unionfs@vger.kernel.org,
kernel-dev@igalia.com
Subject: Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles
Date: Thu, 15 Jan 2026 12:42:33 -0300 [thread overview]
Message-ID: <22b16e24-d10e-43f6-bc2b-eeaa94310e3a@igalia.com> (raw)
In-Reply-To: <20260115072311.GA10352@lst.de>
Em 15/01/2026 04:23, Christoph Hellwig escreveu:
[...]
>
> I still wonder what the use case is here. Looking at André's original
> mail it states:
>
> "However, btrfs mounts may have volatiles UUIDs. When mounting the exact same
> disk image with btrfs, a random UUID is assigned for the following disks each
> time they are mounted, stored at temp_fsid and used across the kernel as the
> disk UUID. `btrfs filesystem show` presents that. Calling statfs() however
> shows the original (and duplicated) UUID for all disks."
>
> and this doesn't even talk about multiple mounts, but looking at
> device_list_add it seems to only set the temp_fsid flag when set
> same_fsid_diff_dev is set by find_fsid_by_device, which isn't documented
> well, but does indeed seem to be done transparently when two file systems
> with the same fsid are mounted.
>
> So André, can you confirm this what you're worried about? And btrfs
> developers, I think the main problem is indeed that btrfs simply allows
> mounting the same fsid twice. Which is really fatal for anything using
> the fsid/uuid, such NFS exports, mount by fs uuid or any sb->s_uuid user.
>
Yes, I'm would like to be able to mount two cloned btrfs images and to
use overlayfs with them. This is useful for SteamOS A/B partition scheme.
>> If so, I think it's time to revert the behavior before it's too late.
>> Currently the main usage of such duplicated fsids is for Steam deck to
>> maintain A/B partitions, I think they can accept a new compat_ro flag for
>> that.
>
> What's an A/B partition? And how are these safely used at the same time?
>
The Steam Deck have two main partitions to install SteamOS updates
atomically. When you want to update the device, assuming that you are
using partition A, the updater will write the new image in partition B,
and vice versa. Then after the reboot, the system will mount the new
image on B.
Android used to support A/B scheme as well:
https://source.android.com/docs/core/ota/ab
next prev parent reply other threads:[~2026-01-15 15:43 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 4:31 [PATCH 0/3] fs: Support btrfs cloned images and overlayfs André Almeida
2026-01-14 4:31 ` [PATCH 1/3] exportfs: Rename get_uuid() to get_disk_uuid() André Almeida
2026-01-14 6:10 ` Darrick J. Wong
2026-01-14 6:24 ` Christoph Hellwig
2026-01-14 10:12 ` Amir Goldstein
2026-01-14 13:11 ` Christoph Hellwig
2026-01-14 16:38 ` André Almeida
2026-01-14 17:58 ` Amir Goldstein
2026-01-14 4:31 ` [PATCH 2/3] btrfs: Implement get_disk_uuid() André Almeida
2026-01-14 4:31 ` [PATCH 3/3] ovl: Use real disk UUID for origin file handles André Almeida
2026-01-14 6:26 ` Christoph Hellwig
2026-01-14 16:17 ` André Almeida
2026-01-15 6:29 ` Christoph Hellwig
2026-01-15 6:51 ` Qu Wenruo
2026-01-15 7:23 ` Christoph Hellwig
2026-01-15 8:09 ` Qu Wenruo
2026-01-15 8:31 ` Christoph Hellwig
2026-01-15 15:42 ` André Almeida [this message]
2026-01-15 16:07 ` Amir Goldstein
2026-01-15 18:55 ` André Almeida
2026-01-16 9:36 ` Christoph Hellwig
2026-01-16 9:55 ` Amir Goldstein
2026-01-16 13:27 ` André Almeida
2026-01-16 17:06 ` Amir Goldstein
2026-01-19 16:56 ` André Almeida
2026-01-20 15:12 ` Amir Goldstein
2026-01-22 20:07 ` Amir Goldstein
2026-01-23 13:24 ` André Almeida
2026-01-23 20:08 ` André Almeida
2026-01-24 10:45 ` Amir Goldstein
2026-01-28 11:49 ` Amir Goldstein
2026-02-05 20:34 ` André Almeida
2026-02-06 13:12 ` Amir Goldstein
2026-02-16 14:59 ` André Almeida
2026-02-17 13:26 ` Amir Goldstein
2026-01-15 16:08 ` Christoph Hellwig
2026-01-14 17:54 ` Amir Goldstein
2026-01-15 6:36 ` Christoph Hellwig
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=22b16e24-d10e-43f6-bc2b-eeaa94310e3a@igalia.com \
--to=andrealmeid@igalia.com \
--cc=Dai.Ngo@oracle.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=cem@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=kernel-dev@igalia.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
--cc=viro@zeniv.linux.org.uk \
--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
all inboxes | Powered by JetHome®