Some filesystem, like btrfs, supports mounting cloned images, but assign
random UUIDs for them to avoid conflicts. This breaks overlayfs "index"
check, given that every time the same image is mounted, it get's
assigned a new UUID.

Fix this assigning the disk UUID for filesystem that implements the
export operation get_disk_uuid(), so overlayfs check is also against the
same value.

Signed-off-by: André Almeida <andrealmeid@igalia.com>
---
 fs/overlayfs/copy_up.c | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index 758611ee4475..8551681fffd3 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -421,8 +421,26 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct inode *realinode,
 	struct ovl_fh *fh;
 	int fh_type, dwords;
 	int buflen = MAX_HANDLE_SZ;
-	uuid_t *uuid = &realinode->i_sb->s_uuid;
-	int err;
+	struct super_block *real_sb = realinode->i_sb;
+	uuid_t *uuid = &real_sb->s_uuid, real_uuid;
+	u32 len = sizeof(uuid_t);
+	int err, ret;
+	u64 offset;
+
+	/*
+	 * Some filesystems that support cloned devices may expose random UUIDs
+	 * for userspace, which will cause the upper root origin check to fail
+	 * during a remount. To avoid this, store the real disk UUID.
+	 *
+	 * ENODATA means that the filesystem implements get_disk_uuid(), but
+	 * this instance is using the real UUID so we can skip the operation.
+	 */
+	if (real_sb->s_export_op && real_sb->s_export_op->get_disk_uuid) {
+		ret = real_sb->s_export_op->get_disk_uuid(real_sb, real_uuid.b, &len, &offset);
+
+		if (!ret || ret != ENODATA)
+			uuid = &real_uuid;
+	}
 
 	/* Make sure the real fid stays 32bit aligned */
 	BUILD_BUG_ON(OVL_FH_FID_OFFSET % 4);

-- 
2.52.0

On Wed, Jan 14, 2026 at 5:32 AM André Almeida <andrealmeid@igalia.com> wrote:
>
> Some filesystem, like btrfs, supports mounting cloned images, but assign
> random UUIDs for them to avoid conflicts. This breaks overlayfs "index"
> check, given that every time the same image is mounted, it get's
> assigned a new UUID.
>
> Fix this assigning the disk UUID for filesystem that implements the
> export operation get_disk_uuid(), so overlayfs check is also against the
> same value.
>
> Signed-off-by: André Almeida <andrealmeid@igalia.com>
> ---
>  fs/overlayfs/copy_up.c | 22 ++++++++++++++++++++--
>  1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
> index 758611ee4475..8551681fffd3 100644
> --- a/fs/overlayfs/copy_up.c
> +++ b/fs/overlayfs/copy_up.c
> @@ -421,8 +421,26 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct inode *realinode,
>         struct ovl_fh *fh;
>         int fh_type, dwords;
>         int buflen = MAX_HANDLE_SZ;
> -       uuid_t *uuid = &realinode->i_sb->s_uuid;
> -       int err;
> +       struct super_block *real_sb = realinode->i_sb;
> +       uuid_t *uuid = &real_sb->s_uuid, real_uuid;
> +       u32 len = sizeof(uuid_t);
> +       int err, ret;
> +       u64 offset;
> +
> +       /*
> +        * Some filesystems that support cloned devices may expose random UUIDs
> +        * for userspace, which will cause the upper root origin check to fail
> +        * during a remount. To avoid this, store the real disk UUID.
> +        *
> +        * ENODATA means that the filesystem implements get_disk_uuid(), but
> +        * this instance is using the real UUID so we can skip the operation.
> +        */
> +       if (real_sb->s_export_op && real_sb->s_export_op->get_disk_uuid) {
> +               ret = real_sb->s_export_op->get_disk_uuid(real_sb, real_uuid.b, &len, &offset);
> +
> +               if (!ret || ret != ENODATA)
> +                       uuid = &real_uuid;
> +       }
>

Perhaps this is the wrong way to abstract what overlayfs needs from real fs.
Maybe better to extend ->encode_fh() to take a flags argument (see similar
suggested patch at [1]) and let overlayfs do something like:

fh_type = 0;
if (ovl_origin_uuid(ofs))
        fh_type = exportfs_encode_inode_fh(realinode, (void *)fh->fb.uuid.b,
                                           &dwords, NULL, EXPORT_FH_WITH_UUID);
if (fh_type <= 0)
        fh_type = exportfs_encode_inode_fh(realinode, (void *)fh->fb.fid,
                                           &dwords, NULL, 0);

Similarly, in ovl_decode_real_fh() overlayfs won't verify the UUID,
this will be also delegated to the filesystem via exportfs_decode_fh()
whose fh->fb.type already has the EXPORT_FH_WITH_UUID flag.

This is very rough hand waving and details need to be worked out,
but it essentially delegates the encoding  of a "globally unique file handle"
to the filesystem without specifying this or that version of uuid.

Thanks,
Amir.

[1] https://lore.kernel.org/linux-fsdevel/CAOQ4uxj=XOFqHBmYY1aBFAnJtSkxzSyPu5G3xP1rx=ZfPfe-kg@mail.gmail.com/

On Wed, Jan 14, 2026 at 06:54:37PM +0100, Amir Goldstein wrote:
> Perhaps this is the wrong way to abstract what overlayfs needs from real fs.
> Maybe better to extend ->encode_fh() to take a flags argument (see similar
> suggested patch at [1]) and let overlayfs do something like:

Encoding the uuid into the file handle in the kernel is the right thing
for NFS as well.  Hacking in the uuids in userspace instead of the kernel
was done initially because there was no good kernel uuid infrastructure.
So doing this in general and have NFS use it when available would be
beneficial for everyone.

On Wed, Jan 14, 2026 at 01:31:43AM -0300, André Almeida wrote:
> Some filesystem, like btrfs, supports mounting cloned images, but assign
> random UUIDs for them to avoid conflicts. This breaks overlayfs "index"
> check, given that every time the same image is mounted, it get's
> assigned a new UUID.

... and the fix is to not assign random uuid, but to assign a new uuid
to the cloned image that is persisted.  That might need a new field
to distintguish the stamped into the format uuid from the visible
uuid like the xfs metauuid, but not hacks like this.

Em 14/01/2026 03:26, Christoph Hellwig escreveu:
> On Wed, Jan 14, 2026 at 01:31:43AM -0300, André Almeida wrote:
>> Some filesystem, like btrfs, supports mounting cloned images, but assign
>> random UUIDs for them to avoid conflicts. This breaks overlayfs "index"
>> check, given that every time the same image is mounted, it get's
>> assigned a new UUID.
> 
> ... and the fix is to not assign random uuid, but to assign a new uuid
> to the cloned image that is persisted.  That might need a new field
> to distintguish the stamped into the format uuid from the visible
> uuid like the xfs metauuid, but not hacks like this.
> 

How can I create this non random and persisting UUID? I was thinking of 
doing some operation on top the original UUID, like a circular shift, 
some sort of rearrangement of the original value that we can always 
reproduce. Is this in the right direction do you think?

On Wed, Jan 14, 2026 at 01:17:15PM -0300, André Almeida wrote:
> Em 14/01/2026 03:26, Christoph Hellwig escreveu:
>> On Wed, Jan 14, 2026 at 01:31:43AM -0300, André Almeida wrote:
>>> Some filesystem, like btrfs, supports mounting cloned images, but assign
>>> random UUIDs for them to avoid conflicts. This breaks overlayfs "index"
>>> check, given that every time the same image is mounted, it get's
>>> assigned a new UUID.
>>
>> ... and the fix is to not assign random uuid, but to assign a new uuid
>> to the cloned image that is persisted.  That might need a new field
>> to distintguish the stamped into the format uuid from the visible
>> uuid like the xfs metauuid, but not hacks like this.
>>
>
> How can I create this non random and persisting UUID? I was thinking of 
> doing some operation on top the original UUID, like a circular shift, some 
> sort of rearrangement of the original value that we can always reproduce. 
> Is this in the right direction do you think?

Just allocate an entirely new uuid?  That's what XFS did with the
metadata uuid (persistent and stapted into all metadata headers) vs
user visible uuid that can be changed.

在 2026/1/15 16:59, Christoph Hellwig 写道:
> On Wed, Jan 14, 2026 at 01:17:15PM -0300, André Almeida wrote:
>> Em 14/01/2026 03:26, Christoph Hellwig escreveu:
>>> On Wed, Jan 14, 2026 at 01:31:43AM -0300, André Almeida wrote:
>>>> Some filesystem, like btrfs, supports mounting cloned images, but assign
>>>> random UUIDs for them to avoid conflicts. This breaks overlayfs "index"
>>>> check, given that every time the same image is mounted, it get's
>>>> assigned a new UUID.
>>>
>>> ... and the fix is to not assign random uuid, but to assign a new uuid
>>> to the cloned image that is persisted.  That might need a new field
>>> to distintguish the stamped into the format uuid from the visible
>>> uuid like the xfs metauuid, but not hacks like this.
>>>
>>
>> How can I create this non random and persisting UUID? I was thinking of
>> doing some operation on top the original UUID, like a circular shift, some
>> sort of rearrangement of the original value that we can always reproduce.
>> Is this in the right direction do you think?
> 
> Just allocate an entirely new uuid?  That's what XFS did with the
> metadata uuid (persistent and stapted into all metadata headers) vs
> user visible uuid that can be changed.

So that means let btrfs to convert the temp fsid into metadata uuid, 
which I think is fine.

But the problem is that will change the fsid of the new fs, which may or 
may not be what's expected for the current temp fsid user (they really 
want two btrfs with the same fsid).


My initial idea for this problem is to let btrfs not generate a tempfsid 
automatically, but put some special flag (e.g. SINGLE_DEV compat ro 
flag) on those fses that want duplicated fsid.

Then for those SINGLE_DEV fses, disable any multi-device related 
features, and use their dev_t to distinguish different fses just like 
EXT4/XFS, without bothering the current tempfsid hack, and just return 
the same fsid.

Unfortunately that idea is not accepted and the current automatic new 
tempfsid solution is merged.

I'm wondering will that behavior (returning the same fsid) be acceptable 
for overlayfs?

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.

Thanks,
Qu

On Thu, Jan 15, 2026 at 05:21:04PM +1030, Qu Wenruo wrote:
> So that means let btrfs to convert the temp fsid into metadata uuid, which 
> I think is fine.

At least in XFS terms, that metadata uuid is the persistent, never
changing uuid in the metadata headrs.

> But the problem is that will change the fsid of the new fs, which may or 
> may not be what's expected for the current temp fsid user (they really want 
> two btrfs with the same fsid).

Which is really dangerous and should not be used in normal operation.
For XFS with support it with a nouuid option, mostly for historic
reasons and to be able to change the uuid transactional using an
ioctl.

> My initial idea for this problem is to let btrfs not generate a tempfsid 
> automatically, but put some special flag (e.g. SINGLE_DEV compat ro flag) 
> on those fses that want duplicated fsid.
>
> Then for those SINGLE_DEV fses, disable any multi-device related features, 
> and use their dev_t to distinguish different fses just like EXT4/XFS, 
> without bothering the current tempfsid hack, and just return the same fsid.

dev_t is not related to the uuid in any way for XFS, and while I'm not
an expert there I'm pretty sure ext4 uses the same not dev related uuid
generation.

> I'm wondering will that behavior (returning the same fsid) be acceptable 
> for overlayfs?

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.

> 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?

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

On Thu, Jan 15, 2026 at 4:42 PM André Almeida <andrealmeid@igalia.com> wrote:
>
> 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.
>

And what do you expect to happen wrt overlayfs when switching from
image A to B?

What are the origin file handles recorded in overlayfs index from image A
lower worth when the lower image is B?

Is there any guarantee that file handles are relevant and point to the
same objects?

The whole point of the overlayfs index feature is that overlayfs inodes
can have a unique id across copy-up.

Please explain in more details exactly which overlayfs setup you are
trying to do with index feature.

FWIW, the setup you are describing sounds very familiar.
I am pretty sure that a similar setup with squashfs and OpenWRT [1]
was the use case to add the uuid=off overlayfs mount options.

Thanks,
Amir.

[1] https://lore.kernel.org/linux-unionfs/32532923.JtPX5UtSzP@fgdesktop/

Em 15/01/2026 13:07, Amir Goldstein escreveu:
> On Thu, Jan 15, 2026 at 4:42 PM André Almeida <andrealmeid@igalia.com> wrote:
>>
>> 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.
>>
> 
> And what do you expect to happen wrt overlayfs when switching from
> image A to B?
> 
> What are the origin file handles recorded in overlayfs index from image A
> lower worth when the lower image is B?
> 
> Is there any guarantee that file handles are relevant and point to the
> same objects?
> 
> The whole point of the overlayfs index feature is that overlayfs inodes
> can have a unique id across copy-up.
> 
> Please explain in more details exactly which overlayfs setup you are
> trying to do with index feature.
> 

The problem happens _before_ switching from A to B, it happens when 
trying to install the same image from A on B.

During the image installation process, while running in A, the B image 
will be mounted more than once for some setup steps, and overlayfs is 
used for this. Because A have the same UUID, each time B is remouted 
will get a new UUID and then the installation scripts fails mounting the 
image.

On Thu, Jan 15, 2026 at 7:55 PM André Almeida <andrealmeid@igalia.com> wrote:
>
> Em 15/01/2026 13:07, Amir Goldstein escreveu:
> > On Thu, Jan 15, 2026 at 4:42 PM André Almeida <andrealmeid@igalia.com> wrote:
> >>
> >> 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.
> >>
> >
> > And what do you expect to happen wrt overlayfs when switching from
> > image A to B?
> >
> > What are the origin file handles recorded in overlayfs index from image A
> > lower worth when the lower image is B?
> >
> > Is there any guarantee that file handles are relevant and point to the
> > same objects?
> >
> > The whole point of the overlayfs index feature is that overlayfs inodes
> > can have a unique id across copy-up.
> >
> > Please explain in more details exactly which overlayfs setup you are
> > trying to do with index feature.
> >
>
> The problem happens _before_ switching from A to B, it happens when
> trying to install the same image from A on B.
>
> During the image installation process, while running in A, the B image
> will be mounted more than once for some setup steps, and overlayfs is
> used for this. Because A have the same UUID, each time B is remouted
> will get a new UUID and then the installation scripts fails mounting the
> image.

Please describe the exact overlayfs setup and specifically,
is it multi lower or single lower layer setup?
What reason do you need the overlayfs index for?
Can you mount with index=off which should relax the hard
requirement for match with the original lower layer uuid.

Thanks,
Amir.

[+CC SteamOS developers]

Em 16/01/2026 06:55, Amir Goldstein escreveu:
> On Thu, Jan 15, 2026 at 7:55 PM André Almeida <andrealmeid@igalia.com> wrote:
>>
>> Em 15/01/2026 13:07, Amir Goldstein escreveu:
>>> On Thu, Jan 15, 2026 at 4:42 PM André Almeida <andrealmeid@igalia.com> wrote:
>>>>
>>>> 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.
>>>>
>>>
>>> And what do you expect to happen wrt overlayfs when switching from
>>> image A to B?
>>>
>>> What are the origin file handles recorded in overlayfs index from image A
>>> lower worth when the lower image is B?
>>>
>>> Is there any guarantee that file handles are relevant and point to the
>>> same objects?
>>>
>>> The whole point of the overlayfs index feature is that overlayfs inodes
>>> can have a unique id across copy-up.
>>>
>>> Please explain in more details exactly which overlayfs setup you are
>>> trying to do with index feature.
>>>
>>
>> The problem happens _before_ switching from A to B, it happens when
>> trying to install the same image from A on B.
>>
>> During the image installation process, while running in A, the B image
>> will be mounted more than once for some setup steps, and overlayfs is
>> used for this. Because A have the same UUID, each time B is remouted
>> will get a new UUID and then the installation scripts fails mounting the
>> image.
> 
> Please describe the exact overlayfs setup and specifically,
> is it multi lower or single lower layer setup?
> What reason do you need the overlayfs index for?
> Can you mount with index=off which should relax the hard
> requirement for match with the original lower layer uuid.
> 

The setup has a single lower layer. This is how the mount command looks 
like:

mount -t overlay -o 
"lowerdir=${DEV_DIR}/etc,upperdir=${DEV_DIR}/var/lib/overlays/etc/upper,workdir=${DEV_DIR}/var/lib/overlays/etc/work" 
none "${DEV_DIR}/etc"

They would rather not disable index, to avoid mounting the wrong layers 
and to avoid corner cases with hardlinks.

On Fri, Jan 16, 2026 at 2:28 PM André Almeida <andrealmeid@igalia.com> wrote:
>
> [+CC SteamOS developers]
>
> Em 16/01/2026 06:55, Amir Goldstein escreveu:
> > On Thu, Jan 15, 2026 at 7:55 PM André Almeida <andrealmeid@igalia.com> wrote:
> >>
> >> Em 15/01/2026 13:07, Amir Goldstein escreveu:
> >>> On Thu, Jan 15, 2026 at 4:42 PM André Almeida <andrealmeid@igalia.com> wrote:
> >>>>
> >>>> 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.
> >>>>
> >>>
> >>> And what do you expect to happen wrt overlayfs when switching from
> >>> image A to B?
> >>>
> >>> What are the origin file handles recorded in overlayfs index from image A
> >>> lower worth when the lower image is B?
> >>>
> >>> Is there any guarantee that file handles are relevant and point to the
> >>> same objects?
> >>>
> >>> The whole point of the overlayfs index feature is that overlayfs inodes
> >>> can have a unique id across copy-up.
> >>>
> >>> Please explain in more details exactly which overlayfs setup you are
> >>> trying to do with index feature.
> >>>
> >>
> >> The problem happens _before_ switching from A to B, it happens when
> >> trying to install the same image from A on B.
> >>
> >> During the image installation process, while running in A, the B image
> >> will be mounted more than once for some setup steps, and overlayfs is
> >> used for this. Because A have the same UUID, each time B is remouted
> >> will get a new UUID and then the installation scripts fails mounting the
> >> image.
> >
> > Please describe the exact overlayfs setup and specifically,
> > is it multi lower or single lower layer setup?
> > What reason do you need the overlayfs index for?
> > Can you mount with index=off which should relax the hard
> > requirement for match with the original lower layer uuid.
> >
>
> The setup has a single lower layer. This is how the mount command looks
> like:
>
> mount -t overlay -o
> "lowerdir=${DEV_DIR}/etc,upperdir=${DEV_DIR}/var/lib/overlays/etc/upper,workdir=${DEV_DIR}/var/lib/overlays/etc/work"
> none "${DEV_DIR}/etc"
>
> They would rather not disable index, to avoid mounting the wrong layers
> and to avoid corner cases with hardlinks.

IIUC you have all the layers on the same fs ($DEV_DIR)?

See mount option uuid=off, created for this exact use case:

Documentation/filesystems/overlayfs.rst:
Note: the mount option uuid=off can be used to replace UUID of the underlying
filesystem in file handles with null, and effectively disable UUID checks. This
can be useful in case the underlying disk is copied and the UUID of this copy
is changed. This is only applicable if all lower/upper/work directories are on
the same filesystem, otherwise it will fallback to normal behaviour.

commit 5830fb6b54f7167cc7c9d43612eb01c24312c7ca
Author: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Date:   Tue Oct 13 17:59:54 2020 +0300

    ovl: introduce new "uuid=off" option for inodes index feature

    This replaces uuid with null in overlayfs file handles and thus relaxes
    uuid checks for overlay index feature. It is only possible in case there is
    only one filesystem for all the work/upper/lower directories and bare file
    handles from this backing filesystem are unique. In other case when we have
    multiple filesystems lets just fallback to "uuid=on" which is and
    equivalent of how it worked before with all uuid checks.

    This is needed when overlayfs is/was mounted in a container with index
    enabled ...

    If you just change the uuid of the backing filesystem, overlay is not
    mounting any more. In Virtuozzo we copy container disks (ploops) when
    create the copy of container and we require fs uuid to be unique for a new
    container.

TBH, I am trying to remember why we require upper/work to be on the
same fs as lower for uuid=off,index=on and I can't remember.
If this is important I can look into it.

Thanks,
Amir.

Em 16/01/2026 14:06, Amir Goldstein escreveu:
> On Fri, Jan 16, 2026 at 2:28 PM André Almeida <andrealmeid@igalia.com> wrote:
>>
>> [+CC SteamOS developers]
>>
>> Em 16/01/2026 06:55, Amir Goldstein escreveu:
>>> On Thu, Jan 15, 2026 at 7:55 PM André Almeida <andrealmeid@igalia.com> wrote:
>>>>
>>>> Em 15/01/2026 13:07, Amir Goldstein escreveu:
>>>>> On Thu, Jan 15, 2026 at 4:42 PM André Almeida <andrealmeid@igalia.com> wrote:
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> And what do you expect to happen wrt overlayfs when switching from
>>>>> image A to B?
>>>>>
>>>>> What are the origin file handles recorded in overlayfs index from image A
>>>>> lower worth when the lower image is B?
>>>>>
>>>>> Is there any guarantee that file handles are relevant and point to the
>>>>> same objects?
>>>>>
>>>>> The whole point of the overlayfs index feature is that overlayfs inodes
>>>>> can have a unique id across copy-up.
>>>>>
>>>>> Please explain in more details exactly which overlayfs setup you are
>>>>> trying to do with index feature.
>>>>>
>>>>
>>>> The problem happens _before_ switching from A to B, it happens when
>>>> trying to install the same image from A on B.
>>>>
>>>> During the image installation process, while running in A, the B image
>>>> will be mounted more than once for some setup steps, and overlayfs is
>>>> used for this. Because A have the same UUID, each time B is remouted
>>>> will get a new UUID and then the installation scripts fails mounting the
>>>> image.
>>>
>>> Please describe the exact overlayfs setup and specifically,
>>> is it multi lower or single lower layer setup?
>>> What reason do you need the overlayfs index for?
>>> Can you mount with index=off which should relax the hard
>>> requirement for match with the original lower layer uuid.
>>>
>>
>> The setup has a single lower layer. This is how the mount command looks
>> like:
>>
>> mount -t overlay -o
>> "lowerdir=${DEV_DIR}/etc,upperdir=${DEV_DIR}/var/lib/overlays/etc/upper,workdir=${DEV_DIR}/var/lib/overlays/etc/work"
>> none "${DEV_DIR}/etc"
>>
>> They would rather not disable index, to avoid mounting the wrong layers
>> and to avoid corner cases with hardlinks.
> 
> IIUC you have all the layers on the same fs ($DEV_DIR)?
> 
> See mount option uuid=off, created for this exact use case:
> 
> Documentation/filesystems/overlayfs.rst:
> Note: the mount option uuid=off can be used to replace UUID of the underlying
> filesystem in file handles with null, and effectively disable UUID checks. This
> can be useful in case the underlying disk is copied and the UUID of this copy
> is changed. This is only applicable if all lower/upper/work directories are on
> the same filesystem, otherwise it will fallback to normal behaviour.
> 
> commit 5830fb6b54f7167cc7c9d43612eb01c24312c7ca
> Author: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
> Date:   Tue Oct 13 17:59:54 2020 +0300
> 
>      ovl: introduce new "uuid=off" option for inodes index feature
> 
>      This replaces uuid with null in overlayfs file handles and thus relaxes
>      uuid checks for overlay index feature. It is only possible in case there is
>      only one filesystem for all the work/upper/lower directories and bare file
>      handles from this backing filesystem are unique. In other case when we have
>      multiple filesystems lets just fallback to "uuid=on" which is and
>      equivalent of how it worked before with all uuid checks.
> 
>      This is needed when overlayfs is/was mounted in a container with index
>      enabled ...
> 
>      If you just change the uuid of the backing filesystem, overlay is not
>      mounting any more. In Virtuozzo we copy container disks (ploops) when
>      create the copy of container and we require fs uuid to be unique for a new
>      container.
> 
> TBH, I am trying to remember why we require upper/work to be on the
> same fs as lower for uuid=off,index=on and I can't remember.
> If this is important I can look into it.
> 

Actually they are not in the same fs, upper and lower are coming from 
different fs', so when trying to mount I get the fallback to 
`uuid=null`. A quick hack circumventing this check makes the mount work.

If you think this is the best way to solve this issue (rather than 
following the VFS helper path for instance), please let me know how can 
I safely lift this restriction, like maybe adding a new flag for this?

> Thanks,
> Amir.

On Mon, Jan 19, 2026 at 5:56 PM André Almeida <andrealmeid@igalia.com> wrote:
>
> Em 16/01/2026 14:06, Amir Goldstein escreveu:
> > On Fri, Jan 16, 2026 at 2:28 PM André Almeida <andrealmeid@igalia.com> wrote:
> >>
> >> [+CC SteamOS developers]
> >>
> >> Em 16/01/2026 06:55, Amir Goldstein escreveu:
> >>> On Thu, Jan 15, 2026 at 7:55 PM André Almeida <andrealmeid@igalia.com> wrote:
> >>>>
> >>>> Em 15/01/2026 13:07, Amir Goldstein escreveu:
> >>>>> On Thu, Jan 15, 2026 at 4:42 PM André Almeida <andrealmeid@igalia.com> wrote:
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>
> >>>>> And what do you expect to happen wrt overlayfs when switching from
> >>>>> image A to B?
> >>>>>
> >>>>> What are the origin file handles recorded in overlayfs index from image A
> >>>>> lower worth when the lower image is B?
> >>>>>
> >>>>> Is there any guarantee that file handles are relevant and point to the
> >>>>> same objects?
> >>>>>
> >>>>> The whole point of the overlayfs index feature is that overlayfs inodes
> >>>>> can have a unique id across copy-up.
> >>>>>
> >>>>> Please explain in more details exactly which overlayfs setup you are
> >>>>> trying to do with index feature.
> >>>>>
> >>>>
> >>>> The problem happens _before_ switching from A to B, it happens when
> >>>> trying to install the same image from A on B.
> >>>>
> >>>> During the image installation process, while running in A, the B image
> >>>> will be mounted more than once for some setup steps, and overlayfs is
> >>>> used for this. Because A have the same UUID, each time B is remouted
> >>>> will get a new UUID and then the installation scripts fails mounting the
> >>>> image.
> >>>
> >>> Please describe the exact overlayfs setup and specifically,
> >>> is it multi lower or single lower layer setup?
> >>> What reason do you need the overlayfs index for?
> >>> Can you mount with index=off which should relax the hard
> >>> requirement for match with the original lower layer uuid.
> >>>
> >>
> >> The setup has a single lower layer. This is how the mount command looks
> >> like:
> >>
> >> mount -t overlay -o
> >> "lowerdir=${DEV_DIR}/etc,upperdir=${DEV_DIR}/var/lib/overlays/etc/upper,workdir=${DEV_DIR}/var/lib/overlays/etc/work"
> >> none "${DEV_DIR}/etc"
> >>
> >> They would rather not disable index, to avoid mounting the wrong layers
> >> and to avoid corner cases with hardlinks.
> >
> > IIUC you have all the layers on the same fs ($DEV_DIR)?
> >
> > See mount option uuid=off, created for this exact use case:
> >
> > Documentation/filesystems/overlayfs.rst:
> > Note: the mount option uuid=off can be used to replace UUID of the underlying
> > filesystem in file handles with null, and effectively disable UUID checks. This
> > can be useful in case the underlying disk is copied and the UUID of this copy
> > is changed. This is only applicable if all lower/upper/work directories are on
> > the same filesystem, otherwise it will fallback to normal behaviour.
> >
> > commit 5830fb6b54f7167cc7c9d43612eb01c24312c7ca
> > Author: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
> > Date:   Tue Oct 13 17:59:54 2020 +0300
> >
> >      ovl: introduce new "uuid=off" option for inodes index feature
> >
> >      This replaces uuid with null in overlayfs file handles and thus relaxes
> >      uuid checks for overlay index feature. It is only possible in case there is
> >      only one filesystem for all the work/upper/lower directories and bare file
> >      handles from this backing filesystem are unique. In other case when we have
> >      multiple filesystems lets just fallback to "uuid=on" which is and
> >      equivalent of how it worked before with all uuid checks.
> >
> >      This is needed when overlayfs is/was mounted in a container with index
> >      enabled ...
> >
> >      If you just change the uuid of the backing filesystem, overlay is not
> >      mounting any more. In Virtuozzo we copy container disks (ploops) when
> >      create the copy of container and we require fs uuid to be unique for a new
> >      container.
> >
> > TBH, I am trying to remember why we require upper/work to be on the
> > same fs as lower for uuid=off,index=on and I can't remember.
> > If this is important I can look into it.
> >
>
> Actually they are not in the same fs, upper and lower are coming from
> different fs', so when trying to mount I get the fallback to
> `uuid=null`. A quick hack circumventing this check makes the mount work.
>
> If you think this is the best way to solve this issue (rather than
> following the VFS helper path for instance),

That's up to you if you want to solve the "all lower layers on same fs"
or want to also allow lower layers on different fs.
The former could be solved by relaxing the ovl rules.

> please let me know how can
> I safely lift this restriction, like maybe adding a new flag for this?

I think the attached patch should work for you and should not
break anything.

It's only sanity tested and will need to write tests to verify it.

Thanks,
Amir.

On Tue, Jan 20, 2026 at 4:12 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Mon, Jan 19, 2026 at 5:56 PM André Almeida <andrealmeid@igalia.com> wrote:
> >
...
> > Actually they are not in the same fs, upper and lower are coming from
> > different fs', so when trying to mount I get the fallback to
> > `uuid=null`. A quick hack circumventing this check makes the mount work.
> >
> > If you think this is the best way to solve this issue (rather than
> > following the VFS helper path for instance),
>
> That's up to you if you want to solve the "all lower layers on same fs"
> or want to also allow lower layers on different fs.
> The former could be solved by relaxing the ovl rules.
>
> > please let me know how can
> > I safely lift this restriction, like maybe adding a new flag for this?
>
> I think the attached patch should work for you and should not
> break anything.
>
> It's only sanity tested and will need to write tests to verify it.
>

Andre,

I tested the patch and it looks good on my side.
If you want me to queue this patch for 7.0,
please let me know if it addresses your use case.

Thanks,
Amir.

Em 22/01/2026 17:07, Amir Goldstein escreveu:
> On Tue, Jan 20, 2026 at 4:12 PM Amir Goldstein <amir73il@gmail.com> wrote:
>>
>> On Mon, Jan 19, 2026 at 5:56 PM André Almeida <andrealmeid@igalia.com> wrote:
>>>
> ...
>>> Actually they are not in the same fs, upper and lower are coming from
>>> different fs', so when trying to mount I get the fallback to
>>> `uuid=null`. A quick hack circumventing this check makes the mount work.
>>>
>>> If you think this is the best way to solve this issue (rather than
>>> following the VFS helper path for instance),
>>
>> That's up to you if you want to solve the "all lower layers on same fs"
>> or want to also allow lower layers on different fs.
>> The former could be solved by relaxing the ovl rules.
>>
>>> please let me know how can
>>> I safely lift this restriction, like maybe adding a new flag for this?
>>
>> I think the attached patch should work for you and should not
>> break anything.
>>
>> It's only sanity tested and will need to write tests to verify it.
>>
> 
> Andre,
> 
> I tested the patch and it looks good on my side.
> If you want me to queue this patch for 7.0,
> please let me know if it addresses your use case.
> 

Hi Amir,

I'm still testing it to make sure it works my case, I will return to you 
ASAP. Thanks for the help!

> Thanks,
> Amir.

Em 23/01/2026 10:24, André Almeida escreveu:
> 
> Em 22/01/2026 17:07, Amir Goldstein escreveu:
>> On Tue, Jan 20, 2026 at 4:12 PM Amir Goldstein <amir73il@gmail.com> 
>> wrote:
>>>
>>> On Mon, Jan 19, 2026 at 5:56 PM André Almeida 
>>> <andrealmeid@igalia.com> wrote:
>>>>
>> ...
>>>> Actually they are not in the same fs, upper and lower are coming from
>>>> different fs', so when trying to mount I get the fallback to
>>>> `uuid=null`. A quick hack circumventing this check makes the mount 
>>>> work.
>>>>
>>>> If you think this is the best way to solve this issue (rather than
>>>> following the VFS helper path for instance),
>>>
>>> That's up to you if you want to solve the "all lower layers on same fs"
>>> or want to also allow lower layers on different fs.
>>> The former could be solved by relaxing the ovl rules.
>>>
>>>> please let me know how can
>>>> I safely lift this restriction, like maybe adding a new flag for this?
>>>
>>> I think the attached patch should work for you and should not
>>> break anything.
>>>
>>> It's only sanity tested and will need to write tests to verify it.
>>>
>>
>> Andre,
>>
>> I tested the patch and it looks good on my side.
>> If you want me to queue this patch for 7.0,
>> please let me know if it addresses your use case.
>>
> 
> Hi Amir,
> 
> I'm still testing it to make sure it works my case, I will return to you 
> ASAP. Thanks for the help!
> 

So, your patch wasn't initially working in my setup here, and after some 
debugging it turns out that on ovl_verify_fh() *fh would have a NULL 
UUID, but *ofh would have a valid UUID, so the compare would then fail.

Adding this line at ovl_get_fh() fixed the issue for me and made the 
patch work as I was expecting:

+       if (!ovl_origin_uuid(ofs))
+               fh->fb.uuid = uuid_null;
+
         return fh;

Please let me know if that makes sense to you.

Thanks!
	André

On Fri, Jan 23, 2026 at 9:08 PM André Almeida <andrealmeid@igalia.com> wrote:
>
> Em 23/01/2026 10:24, André Almeida escreveu:
> >
> > Em 22/01/2026 17:07, Amir Goldstein escreveu:
> >> On Tue, Jan 20, 2026 at 4:12 PM Amir Goldstein <amir73il@gmail.com>
> >> wrote:
> >>>
> >>> On Mon, Jan 19, 2026 at 5:56 PM André Almeida
> >>> <andrealmeid@igalia.com> wrote:
> >>>>
> >> ...
> >>>> Actually they are not in the same fs, upper and lower are coming from
> >>>> different fs', so when trying to mount I get the fallback to
> >>>> `uuid=null`. A quick hack circumventing this check makes the mount
> >>>> work.
> >>>>
> >>>> If you think this is the best way to solve this issue (rather than
> >>>> following the VFS helper path for instance),
> >>>
> >>> That's up to you if you want to solve the "all lower layers on same fs"
> >>> or want to also allow lower layers on different fs.
> >>> The former could be solved by relaxing the ovl rules.
> >>>
> >>>> please let me know how can
> >>>> I safely lift this restriction, like maybe adding a new flag for this?
> >>>
> >>> I think the attached patch should work for you and should not
> >>> break anything.
> >>>
> >>> It's only sanity tested and will need to write tests to verify it.
> >>>
> >>
> >> Andre,
> >>
> >> I tested the patch and it looks good on my side.
> >> If you want me to queue this patch for 7.0,
> >> please let me know if it addresses your use case.
> >>
> >
> > Hi Amir,
> >
> > I'm still testing it to make sure it works my case, I will return to you
> > ASAP. Thanks for the help!
> >
>
> So, your patch wasn't initially working in my setup here, and after some
> debugging it turns out that on ovl_verify_fh() *fh would have a NULL
> UUID, but *ofh would have a valid UUID, so the compare would then fail.
>
> Adding this line at ovl_get_fh() fixed the issue for me and made the
> patch work as I was expecting:
>
> +       if (!ovl_origin_uuid(ofs))
> +               fh->fb.uuid = uuid_null;
> +
>          return fh;
>
> Please let me know if that makes sense to you.

It does not make sense to me.
I think you may be using the uuid=off feature in the wrong way.
What you did was to change the stored UUID, but this NOT the
purpose of uuid=off.

The purpose of uuid=off is NOT to allow mounting an overlayfs
that was previously using a different lower UUID.
The purpose is to mount overlayfs the from the FIRST time with
uuid=off so that ovl_verify_origin_fh() gets null uuid from the
first call that sets the ORIGIN xattr.

IOW, if user want to be able to change underlying later UUID
user needs to declare from the first overlayfs mount that this
is expected to happen, otherwise, overlayfs will assume that
an unintentional wrong configuration was used.

I updated the documentation to try to explain this better:

Is my understanding of the problems you had correct?
Is my solution understood and applicable to your use case?

Thanks,
Amir.

diff --git a/Documentation/filesystems/overlayfs.rst
b/Documentation/filesystems/overlayfs.rst
index ab989807a2cb6..af5a69f87da42 100644
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -753,9 +753,9 @@ Note: the mount options index=off,nfs_export=on
are conflicting for a
 read-write mount and will result in an error.

 Note: the mount option uuid=off can be used to replace UUID of the underlying
-filesystem in file handles with null, and effectively disable UUID checks. This
+filesystem in file handles with null, in order to relax the UUID checks. This
 can be useful in case the underlying disk is copied and the UUID of this copy
-is changed. This is only applicable if all lower/upper/work directories are on
+is changed. This is only applicable if all lower directories are on
 the same filesystem, otherwise it will fallback to normal behaviour.


@@ -769,7 +769,7 @@ controlled by the "uuid" mount option, which
supports these values:
     UUID of overlayfs is null. fsid is taken from upper most filesystem.
 - "off":
     UUID of overlayfs is null. fsid is taken from upper most filesystem.
-    UUID of underlying layers is ignored.
+    UUID of underlying layers is ignored and null used instead.
 - "on":
     UUID of overlayfs is generated and used to report a unique fsid.
     UUID is stored in xattr "trusted.overlay.uuid", making overlayfs fsid

On Sat, Jan 24, 2026 at 11:45 AM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Fri, Jan 23, 2026 at 9:08 PM André Almeida <andrealmeid@igalia.com> wrote:
> >
> > Em 23/01/2026 10:24, André Almeida escreveu:
> > >
> > > Em 22/01/2026 17:07, Amir Goldstein escreveu:
> > >> On Tue, Jan 20, 2026 at 4:12 PM Amir Goldstein <amir73il@gmail.com>
> > >> wrote:
> > >>>
> > >>> On Mon, Jan 19, 2026 at 5:56 PM André Almeida
> > >>> <andrealmeid@igalia.com> wrote:
> > >>>>
> > >> ...
> > >>>> Actually they are not in the same fs, upper and lower are coming from
> > >>>> different fs', so when trying to mount I get the fallback to
> > >>>> `uuid=null`. A quick hack circumventing this check makes the mount
> > >>>> work.
> > >>>>
> > >>>> If you think this is the best way to solve this issue (rather than
> > >>>> following the VFS helper path for instance),
> > >>>
> > >>> That's up to you if you want to solve the "all lower layers on same fs"
> > >>> or want to also allow lower layers on different fs.
> > >>> The former could be solved by relaxing the ovl rules.
> > >>>
> > >>>> please let me know how can
> > >>>> I safely lift this restriction, like maybe adding a new flag for this?
> > >>>
> > >>> I think the attached patch should work for you and should not
> > >>> break anything.
> > >>>
> > >>> It's only sanity tested and will need to write tests to verify it.
> > >>>
> > >>
> > >> Andre,
> > >>
> > >> I tested the patch and it looks good on my side.
> > >> If you want me to queue this patch for 7.0,
> > >> please let me know if it addresses your use case.
> > >>
> > >
> > > Hi Amir,
> > >
> > > I'm still testing it to make sure it works my case, I will return to you
> > > ASAP. Thanks for the help!
> > >
> >
> > So, your patch wasn't initially working in my setup here, and after some
> > debugging it turns out that on ovl_verify_fh() *fh would have a NULL
> > UUID, but *ofh would have a valid UUID, so the compare would then fail.
> >
> > Adding this line at ovl_get_fh() fixed the issue for me and made the
> > patch work as I was expecting:
> >
> > +       if (!ovl_origin_uuid(ofs))
> > +               fh->fb.uuid = uuid_null;
> > +
> >          return fh;
> >
> > Please let me know if that makes sense to you.
>
> It does not make sense to me.
> I think you may be using the uuid=off feature in the wrong way.
> What you did was to change the stored UUID, but this NOT the
> purpose of uuid=off.
>
> The purpose of uuid=off is NOT to allow mounting an overlayfs
> that was previously using a different lower UUID.
> The purpose is to mount overlayfs the from the FIRST time with
> uuid=off so that ovl_verify_origin_fh() gets null uuid from the
> first call that sets the ORIGIN xattr.
>
> IOW, if user want to be able to change underlying later UUID
> user needs to declare from the first overlayfs mount that this
> is expected to happen, otherwise, overlayfs will assume that
> an unintentional wrong configuration was used.
>
> I updated the documentation to try to explain this better:
>
> Is my understanding of the problems you had correct?
> Is my solution understood and applicable to your use case?
>

Hi Andre,

Sorry to nag you, but if you'd like me to queue the suggested change to 7.0,
I would need your feedback soon.

FWIW, I think that this change of restrictions for uuid=null could be backported
to stable kernels, but I am not going to mark it for auto select, because
I'd rather see if anyone shouts with upstream kernel first when (if) we make
this change and manually backport later per demand.

Thanks,
Amir.

Em 28/01/2026 08:49, Amir Goldstein escreveu:
> On Sat, Jan 24, 2026 at 11:45 AM Amir Goldstein <amir73il@gmail.com> wrote:
>>
>> On Fri, Jan 23, 2026 at 9:08 PM André Almeida <andrealmeid@igalia.com> wrote:
>>>
>>> Em 23/01/2026 10:24, André Almeida escreveu:
>>>>
>>>> Em 22/01/2026 17:07, Amir Goldstein escreveu:
>>>>> On Tue, Jan 20, 2026 at 4:12 PM Amir Goldstein <amir73il@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On Mon, Jan 19, 2026 at 5:56 PM André Almeida
>>>>>> <andrealmeid@igalia.com> wrote:
>>>>>>>
>>>>> ...
>>>>>>> Actually they are not in the same fs, upper and lower are coming from
>>>>>>> different fs', so when trying to mount I get the fallback to
>>>>>>> `uuid=null`. A quick hack circumventing this check makes the mount
>>>>>>> work.
>>>>>>>
>>>>>>> If you think this is the best way to solve this issue (rather than
>>>>>>> following the VFS helper path for instance),
>>>>>>
>>>>>> That's up to you if you want to solve the "all lower layers on same fs"
>>>>>> or want to also allow lower layers on different fs.
>>>>>> The former could be solved by relaxing the ovl rules.
>>>>>>
>>>>>>> please let me know how can
>>>>>>> I safely lift this restriction, like maybe adding a new flag for this?
>>>>>>
>>>>>> I think the attached patch should work for you and should not
>>>>>> break anything.
>>>>>>
>>>>>> It's only sanity tested and will need to write tests to verify it.
>>>>>>
>>>>>
>>>>> Andre,
>>>>>
>>>>> I tested the patch and it looks good on my side.
>>>>> If you want me to queue this patch for 7.0,
>>>>> please let me know if it addresses your use case.
>>>>>
>>>>
>>>> Hi Amir,
>>>>
>>>> I'm still testing it to make sure it works my case, I will return to you
>>>> ASAP. Thanks for the help!
>>>>
>>>
>>> So, your patch wasn't initially working in my setup here, and after some
>>> debugging it turns out that on ovl_verify_fh() *fh would have a NULL
>>> UUID, but *ofh would have a valid UUID, so the compare would then fail.
>>>
>>> Adding this line at ovl_get_fh() fixed the issue for me and made the
>>> patch work as I was expecting:
>>>
>>> +       if (!ovl_origin_uuid(ofs))
>>> +               fh->fb.uuid = uuid_null;
>>> +
>>>           return fh;
>>>
>>> Please let me know if that makes sense to you.
>>
>> It does not make sense to me.
>> I think you may be using the uuid=off feature in the wrong way.
>> What you did was to change the stored UUID, but this NOT the
>> purpose of uuid=off.
>>
>> The purpose of uuid=off is NOT to allow mounting an overlayfs
>> that was previously using a different lower UUID.
>> The purpose is to mount overlayfs the from the FIRST time with
>> uuid=off so that ovl_verify_origin_fh() gets null uuid from the
>> first call that sets the ORIGIN xattr.
>>
>> IOW, if user want to be able to change underlying later UUID
>> user needs to declare from the first overlayfs mount that this
>> is expected to happen, otherwise, overlayfs will assume that
>> an unintentional wrong configuration was used.
>>
>> I updated the documentation to try to explain this better:
>>
>> Is my understanding of the problems you had correct?
>> Is my solution understood and applicable to your use case?
>>
> 
> Hi Andre,
> 
> Sorry to nag you, but if you'd like me to queue the suggested change to 7.0,
> I would need your feedback soon.
> 

Hey Amir, sorry for my delay. I just had a week out of the office and 
just got back to this.

Our initial test case worked great! We managed to mount both images and 
use overlayfs without a problem after your clarification of where to use 
uuid=off, which should be on the first mount.

However, when rebooting to the other partition, the mount failed with 
"failed to verify upper root origin" again, but I believe that I forgot 
to add `uuid=off` somewhere in the mount scripts. I'm still debugging this.

Anyhow, I see that we are now too close to the merge window, and from my 
side we can delay this for 7.1 and merge it when it gets 100% clear that 
this is the solution that we are looking for.

Thanks again for your help!
	André

> FWIW, I think that this change of restrictions for uuid=null could be backported
> to stable kernels, but I am not going to mark it for auto select, because
> I'd rather see if anyone shouts with upstream kernel first when (if) we make
> this change and manually backport later per demand.
> 
> Thanks,
> Amir.

On Thu, Feb 5, 2026 at 9:34 PM André Almeida <andrealmeid@igalia.com> wrote:
>
> Em 28/01/2026 08:49, Amir Goldstein escreveu:
> > On Sat, Jan 24, 2026 at 11:45 AM Amir Goldstein <amir73il@gmail.com> wrote:
> >>
> >> On Fri, Jan 23, 2026 at 9:08 PM André Almeida <andrealmeid@igalia.com> wrote:
> >>>
> >>> Em 23/01/2026 10:24, André Almeida escreveu:
> >>>>
> >>>> Em 22/01/2026 17:07, Amir Goldstein escreveu:
> >>>>> On Tue, Jan 20, 2026 at 4:12 PM Amir Goldstein <amir73il@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> On Mon, Jan 19, 2026 at 5:56 PM André Almeida
> >>>>>> <andrealmeid@igalia.com> wrote:
> >>>>>>>
> >>>>> ...
> >>>>>>> Actually they are not in the same fs, upper and lower are coming from
> >>>>>>> different fs', so when trying to mount I get the fallback to
> >>>>>>> `uuid=null`. A quick hack circumventing this check makes the mount
> >>>>>>> work.
> >>>>>>>
> >>>>>>> If you think this is the best way to solve this issue (rather than
> >>>>>>> following the VFS helper path for instance),
> >>>>>>
> >>>>>> That's up to you if you want to solve the "all lower layers on same fs"
> >>>>>> or want to also allow lower layers on different fs.
> >>>>>> The former could be solved by relaxing the ovl rules.
> >>>>>>
> >>>>>>> please let me know how can
> >>>>>>> I safely lift this restriction, like maybe adding a new flag for this?
> >>>>>>
> >>>>>> I think the attached patch should work for you and should not
> >>>>>> break anything.
> >>>>>>
> >>>>>> It's only sanity tested and will need to write tests to verify it.
> >>>>>>
> >>>>>
> >>>>> Andre,
> >>>>>
> >>>>> I tested the patch and it looks good on my side.
> >>>>> If you want me to queue this patch for 7.0,
> >>>>> please let me know if it addresses your use case.
> >>>>>
> >>>>
> >>>> Hi Amir,
> >>>>
> >>>> I'm still testing it to make sure it works my case, I will return to you
> >>>> ASAP. Thanks for the help!
> >>>>
> >>>
> >>> So, your patch wasn't initially working in my setup here, and after some
> >>> debugging it turns out that on ovl_verify_fh() *fh would have a NULL
> >>> UUID, but *ofh would have a valid UUID, so the compare would then fail.
> >>>
> >>> Adding this line at ovl_get_fh() fixed the issue for me and made the
> >>> patch work as I was expecting:
> >>>
> >>> +       if (!ovl_origin_uuid(ofs))
> >>> +               fh->fb.uuid = uuid_null;
> >>> +
> >>>           return fh;
> >>>
> >>> Please let me know if that makes sense to you.
> >>
> >> It does not make sense to me.
> >> I think you may be using the uuid=off feature in the wrong way.
> >> What you did was to change the stored UUID, but this NOT the
> >> purpose of uuid=off.
> >>
> >> The purpose of uuid=off is NOT to allow mounting an overlayfs
> >> that was previously using a different lower UUID.
> >> The purpose is to mount overlayfs the from the FIRST time with
> >> uuid=off so that ovl_verify_origin_fh() gets null uuid from the
> >> first call that sets the ORIGIN xattr.
> >>
> >> IOW, if user want to be able to change underlying later UUID
> >> user needs to declare from the first overlayfs mount that this
> >> is expected to happen, otherwise, overlayfs will assume that
> >> an unintentional wrong configuration was used.
> >>
> >> I updated the documentation to try to explain this better:
> >>
> >> Is my understanding of the problems you had correct?
> >> Is my solution understood and applicable to your use case?
> >>
> >
> > Hi Andre,
> >
> > Sorry to nag you, but if you'd like me to queue the suggested change to 7.0,
> > I would need your feedback soon.
> >
>
> Hey Amir, sorry for my delay. I just had a week out of the office and
> just got back to this.
>
> Our initial test case worked great! We managed to mount both images and
> use overlayfs without a problem after your clarification of where to use
> uuid=off, which should be on the first mount.

Not only on the *first* mount - on *all* the mounts.
Unless you use "uuid=off" consistently, overlayfs will deny the mount.

>
> However, when rebooting to the other partition, the mount failed with
> "failed to verify upper root origin" again, but I believe that I forgot
> to add `uuid=off` somewhere in the mount scripts. I'm still debugging this.

Not sure what you mean by "other partition"
Overlayfs verifies the origin by file handle + UUID.
We allow relaxing UUID check with uuid=off
but isn't it the case for btrfs that the same file in different
clones will have a different file handle, because of different
root_objectid?

        fid->objectid = btrfs_ino(BTRFS_I(inode));
        fid->root_objectid = btrfs_root_id(BTRFS_I(inode)->root);
        fid->gen = inode->i_generation;

That means that you can use "uuid=off" to overcome the
ephemeral nature of the btrfs clone UUID, but you cannot
use it to mount an overlayfs that was created in one btrfs
clone from another clone.

Sorry, no "fileid=off" option, this is out of the question.

You are free to use "index=off" to avoid those requirements,
but the essence of "index=on" is that the lower file can be uniquely
identified and therefore, changing the lower file's unique id is game over.

>
> Anyhow, I see that we are now too close to the merge window, and from my
> side we can delay this for 7.1 and merge it when it gets 100% clear that
> this is the solution that we are looking for.
>

I pushed this patch to overlayfs-next branch.
It is an internal logic change in overlayfs that does not conflict with
other code, so there should not be a problem to send a PR on the
second half of the 7.0 merge window if this is useful.

I think that the change itself makes sense because there was never
a justification for the strict rule of both upper/lower on the same fs
for uuid=off, but I am still not going to send it without knowing that
someone finds this useful for their workload.

Thanks,
Amir.

On Thu, Jan 15, 2026 at 03:55:15PM -0300, André Almeida wrote:
>> Is there any guarantee that file handles are relevant and point to the
>> same objects?
>>
>> The whole point of the overlayfs index feature is that overlayfs inodes
>> can have a unique id across copy-up.
>>
>> Please explain in more details exactly which overlayfs setup you are
>> trying to do with index feature.
>>
>
> The problem happens _before_ switching from A to B, it happens when trying 
> to install the same image from A on B.
>
> During the image installation process, while running in A, the B image will 
> be mounted more than once for some setup steps, and overlayfs is used for 
> this. Because A have the same UUID, each time B is remouted will get a new 
> UUID and then the installation scripts fails mounting the image.

It sounds like the 'clones' really need different persistent uuids. Or
do you also have a requirement that the two images have the same ID,
which would require a noouid-like option and extremely careful handling.

On Thu, Jan 15, 2026 at 12:42:33PM -0300, André Almeida wrote:
>> 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.

Then you'll really need to assign them different (persistent) fsids/uuids.

在 2026/1/15 17:53, Christoph Hellwig 写道:
> On Thu, Jan 15, 2026 at 05:21:04PM +1030, Qu Wenruo wrote:
>> So that means let btrfs to convert the temp fsid into metadata uuid, which
>> I think is fine.
> 
> At least in XFS terms, that metadata uuid is the persistent, never
> changing uuid in the metadata headrs.
> 
>> But the problem is that will change the fsid of the new fs, which may or
>> may not be what's expected for the current temp fsid user (they really want
>> two btrfs with the same fsid).
> 
> Which is really dangerous and should not be used in normal operation.
> For XFS with support it with a nouuid option, mostly for historic
> reasons and to be able to change the uuid transactional using an
> ioctl.
> 
>> My initial idea for this problem is to let btrfs not generate a tempfsid
>> automatically, but put some special flag (e.g. SINGLE_DEV compat ro flag)
>> on those fses that want duplicated fsid.
>>
>> Then for those SINGLE_DEV fses, disable any multi-device related features,
>> and use their dev_t to distinguish different fses just like EXT4/XFS,
>> without bothering the current tempfsid hack, and just return the same fsid.
> 
> dev_t is not related to the uuid in any way for XFS, and while I'm not
> an expert there I'm pretty sure ext4 uses the same not dev related uuid
> generation.

My bad, by dev_t I mean bdev holder, which is a pointer to the super 
block of the mounted fs. (And btrfs just recently join this common usage)

> 
>> I'm wondering will that behavior (returning the same fsid) be acceptable
>> for overlayfs?
> 
> 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.

Yeah, although it's possible to mount different devices with same fsid 
separately, I don't think it's really that a good idea either.

Thus I really prefer to have special flags for those "uncommon" use 
cases, other than the current automatically enabled tempfsid feature.

It's like introducing a lot of complexity for a corner case, and that's 
also affecting our common routines.


On the other hand, ext4 allows to mount two cloned fses, mostly thanks 
to the above bdev holder mechanism.


For regular stat() calls, we can still distinguish the two different 
fses with the same fsid, they have two different st_dev members.
But not sure how overlayfs would be able to distinguish such two fses.

> 
>> 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?
> 

For the original thread about A/B partition usage:

https://lore.kernel.org/linux-btrfs/20230504170708.787361-1-gpiccoli@igalia.com/

And

https://lore.kernel.org/linux-btrfs/c702fe27-8da9-505b-6e27-713edacf723a@igalia.com/

Thanks,
Qu

On Thu, Jan 15, 2026 at 06:39:05PM +1030, Qu Wenruo wrote:
>>> Then for those SINGLE_DEV fses, disable any multi-device related features,
>>> and use their dev_t to distinguish different fses just like EXT4/XFS,
>>> without bothering the current tempfsid hack, and just return the same fsid.
>>
>> dev_t is not related to the uuid in any way for XFS, and while I'm not
>> an expert there I'm pretty sure ext4 uses the same not dev related uuid
>> generation.
>
> My bad, by dev_t I mean bdev holder, which is a pointer to the super block 
> of the mounted fs. (And btrfs just recently join this common usage)

How is that related?  That prevents multiple callers from exclusively
using a block device.  Cloned file systems will sit on different devices.

> Yeah, although it's possible to mount different devices with same fsid 
> separately, I don't think it's really that a good idea either.
>
> Thus I really prefer to have special flags for those "uncommon" use cases, 
> other than the current automatically enabled tempfsid feature.

For XFS we require the nouuid option to allows additional mounts of
file systems with the same uuid.  I think that is the equivalent to
what btrfs calls the fsid.