[PATCH 0/3] fs: Support btrfs cloned images and overlayfs

[PATCH 0/3] fs: Support btrfs cloned images and overlayfs

[André Almeida]

Hi everyone,

As I reported some time ago, btrfs cloned images support and overlayfs
"index" check don't get along together[1]. Every time the same image
cloned is mounted, btrfs assigns a new random UUID for it to avoid
clashing with the exist UUID. This UUID is then used by overlayfs origin
check, to avoid reusing the same directory for a different filesystem.
Remounting the same filesystem in the same directory is supported, but
the different random UUIDs will make the check fail.

In an attempt to solve this, I reused export_operations::get_uuid() for
this purpose, to get the "real" UUID of a image, regardless of the
random UUID being exposed to userspace. overlayfs then use this UUID
internally for the origin check, and the remounting finally works.

I understand that not everyone is happy about repurposing get_uuid() for
that, but I'm totally open for going in another direction for solving
this problem not only for the combination of btrfs+overlayfs, but for
any filesytem that have similar issues with random UUIDs.

Using `btrfstune -m` or similar to change the cloned image UUID doesn't
work for the SteamOS use case, as we, well... use the UUIDs to identify
unmounted images and check if they are the same.

This series is based on top of another series[2], that should be available
at vfs-7.0.misc by now.

Thanks!

[1] https://lore.kernel.org/lkml/20251014015707.129013-1-andrealmeid@igalia.com/
[2] https://lore.kernel.org/lkml/20260112-tonyk-fs_uuid-v1-0-acc1889de772@igalia.com/

---
André Almeida (3):
      exportfs: Rename get_uuid() to get_disk_uuid()
      btrfs: Implement get_disk_uuid()
      ovl: Use real disk UUID for origin file handles

 fs/btrfs/export.c        | 20 ++++++++++++++++++++
 fs/nfsd/blocklayout.c    |  2 +-
 fs/nfsd/nfs4layouts.c    |  2 +-
 fs/overlayfs/copy_up.c   | 22 ++++++++++++++++++++--
 fs/xfs/xfs_export.c      |  2 +-
 fs/xfs/xfs_pnfs.c        |  2 +-
 fs/xfs/xfs_pnfs.h        |  2 +-
 include/linux/exportfs.h |  8 +++++---
 8 files changed, 50 insertions(+), 10 deletions(-)
---
base-commit: 336cebc7376296b2c25cf8433ff62b71fe929b0d
change-id: 20260114-tonyk-get_disk_uuid-f0d475ed170c

Best regards,
-- 
André Almeida <andrealmeid@igalia.com>

[PATCH 1/3] exportfs: Rename get_uuid() to get_disk_uuid()

[André Almeida]

To make clear which UUID is being returned, rename get_uuid() to
get_disk_uuid(). Expand the function documentation to note that this
function can be also used for filesystem that supports cloned devices
that might have different UUIDs for userspace tools, while having the
same UUID for internal usage.

Signed-off-by: André Almeida <andrealmeid@igalia.com>
---
 fs/nfsd/blocklayout.c    | 2 +-
 fs/nfsd/nfs4layouts.c    | 2 +-
 fs/xfs/xfs_export.c      | 2 +-
 fs/xfs/xfs_pnfs.c        | 2 +-
 fs/xfs/xfs_pnfs.h        | 2 +-
 include/linux/exportfs.h | 8 +++++---
 6 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/fs/nfsd/blocklayout.c b/fs/nfsd/blocklayout.c
index afa16d7a8013..713a1f69f8fe 100644
--- a/fs/nfsd/blocklayout.c
+++ b/fs/nfsd/blocklayout.c
@@ -218,7 +218,7 @@ nfsd4_block_get_device_info_simple(struct super_block *sb,
 
 	b->type = PNFS_BLOCK_VOLUME_SIMPLE;
 	b->simple.sig_len = PNFS_BLOCK_UUID_LEN;
-	return sb->s_export_op->get_uuid(sb, b->simple.sig, &b->simple.sig_len,
+	return sb->s_export_op->get_disk_uuid(sb, b->simple.sig, &b->simple.sig_len,
 			&b->simple.offset);
 }
 
diff --git a/fs/nfsd/nfs4layouts.c b/fs/nfsd/nfs4layouts.c
index ad7af8cfcf1f..50bb29b2017c 100644
--- a/fs/nfsd/nfs4layouts.c
+++ b/fs/nfsd/nfs4layouts.c
@@ -136,7 +136,7 @@ void nfsd4_setup_layout_type(struct svc_export *exp)
 	exp->ex_layout_types |= 1 << LAYOUT_FLEX_FILES;
 #endif
 #ifdef CONFIG_NFSD_BLOCKLAYOUT
-	if (sb->s_export_op->get_uuid &&
+	if (sb->s_export_op->get_disk_uuid &&
 	    sb->s_export_op->map_blocks &&
 	    sb->s_export_op->commit_blocks)
 		exp->ex_layout_types |= 1 << LAYOUT_BLOCK_VOLUME;
diff --git a/fs/xfs/xfs_export.c b/fs/xfs/xfs_export.c
index 201489d3de08..d09570ba7445 100644
--- a/fs/xfs/xfs_export.c
+++ b/fs/xfs/xfs_export.c
@@ -244,7 +244,7 @@ const struct export_operations xfs_export_operations = {
 	.get_parent		= xfs_fs_get_parent,
 	.commit_metadata	= xfs_fs_nfs_commit_metadata,
 #ifdef CONFIG_EXPORTFS_BLOCK_OPS
-	.get_uuid		= xfs_fs_get_uuid,
+	.get_disk_uuid		= xfs_fs_get_disk_uuid,
 	.map_blocks		= xfs_fs_map_blocks,
 	.commit_blocks		= xfs_fs_commit_blocks,
 #endif
diff --git a/fs/xfs/xfs_pnfs.c b/fs/xfs/xfs_pnfs.c
index afe7497012d4..6ef7b29c4060 100644
--- a/fs/xfs/xfs_pnfs.c
+++ b/fs/xfs/xfs_pnfs.c
@@ -50,7 +50,7 @@ xfs_break_leased_layouts(
  * the exported device.
  */
 int
-xfs_fs_get_uuid(
+xfs_fs_get_disk_uuid(
 	struct super_block	*sb,
 	u8			*buf,
 	u32			*len,
diff --git a/fs/xfs/xfs_pnfs.h b/fs/xfs/xfs_pnfs.h
index 940c6c2ad88c..df82a6ba1a11 100644
--- a/fs/xfs/xfs_pnfs.h
+++ b/fs/xfs/xfs_pnfs.h
@@ -3,7 +3,7 @@
 #define _XFS_PNFS_H 1
 
 #ifdef CONFIG_EXPORTFS_BLOCK_OPS
-int xfs_fs_get_uuid(struct super_block *sb, u8 *buf, u32 *len, u64 *offset);
+int xfs_fs_get_disk_uuid(struct super_block *sb, u8 *buf, u32 *len, u64 *offset);
 int xfs_fs_map_blocks(struct inode *inode, loff_t offset, u64 length,
 		struct iomap *iomap, bool write, u32 *device_generation);
 int xfs_fs_commit_blocks(struct inode *inode, struct iomap *maps, int nr_maps,
diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
index 262e24d83313..dc7029949a62 100644
--- a/include/linux/exportfs.h
+++ b/include/linux/exportfs.h
@@ -252,8 +252,10 @@ struct handle_to_path_ctx {
  * @commit_metadata:
  *    @commit_metadata should commit metadata changes to stable storage.
  *
- * @get_uuid:
- *    Get a filesystem unique signature exposed to clients.
+ * @get_disk_uuid:
+ *    Get a filesystem unique signature exposed to clients. It's also useful for
+ *    filesystems that support mounting cloned disks and export different UUIDs
+ *    for userspace, while being internally the same.
  *
  * @map_blocks:
  *    Map and, if necessary, allocate blocks for a layout.
@@ -282,7 +284,7 @@ struct export_operations {
 	struct dentry * (*get_parent)(struct dentry *child);
 	int (*commit_metadata)(struct inode *inode);
 
-	int (*get_uuid)(struct super_block *sb, u8 *buf, u32 *len, u64 *offset);
+	int (*get_disk_uuid)(struct super_block *sb, u8 *buf, u32 *len, u64 *offset);
 	int (*map_blocks)(struct inode *inode, loff_t offset,
 			  u64 len, struct iomap *iomap,
 			  bool write, u32 *device_generation);

-- 
2.52.0

Re: [PATCH 1/3] exportfs: Rename get_uuid() to get_disk_uuid()

[Darrick J. Wong]

On Wed, Jan 14, 2026 at 01:31:41AM -0300, André Almeida wrote:
> To make clear which UUID is being returned, rename get_uuid() to
> get_disk_uuid(). Expand the function documentation to note that this
> function can be also used for filesystem that supports cloned devices
> that might have different UUIDs for userspace tools, while having the
> same UUID for internal usage.

I'm not sure what a "disk uuid" is -- XFS can store two of them in the
ondisk superblock: the admin-modifiable one that blkid reports, and the
secret one that's stamped in all the metadata and cannot change.

IIRC XFS only shares the user-visible UUID, but they're both from the
disk.   Also I'm not sure what a non-disk filesystem is supposed to
provide here?

--D

> Signed-off-by: André Almeida <andrealmeid@igalia.com>
> ---
>  fs/nfsd/blocklayout.c    | 2 +-
>  fs/nfsd/nfs4layouts.c    | 2 +-
>  fs/xfs/xfs_export.c      | 2 +-
>  fs/xfs/xfs_pnfs.c        | 2 +-
>  fs/xfs/xfs_pnfs.h        | 2 +-
>  include/linux/exportfs.h | 8 +++++---
>  6 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/nfsd/blocklayout.c b/fs/nfsd/blocklayout.c
> index afa16d7a8013..713a1f69f8fe 100644
> --- a/fs/nfsd/blocklayout.c
> +++ b/fs/nfsd/blocklayout.c
> @@ -218,7 +218,7 @@ nfsd4_block_get_device_info_simple(struct super_block *sb,
>  
>  	b->type = PNFS_BLOCK_VOLUME_SIMPLE;
>  	b->simple.sig_len = PNFS_BLOCK_UUID_LEN;
> -	return sb->s_export_op->get_uuid(sb, b->simple.sig, &b->simple.sig_len,
> +	return sb->s_export_op->get_disk_uuid(sb, b->simple.sig, &b->simple.sig_len,
>  			&b->simple.offset);
>  }
>  
> diff --git a/fs/nfsd/nfs4layouts.c b/fs/nfsd/nfs4layouts.c
> index ad7af8cfcf1f..50bb29b2017c 100644
> --- a/fs/nfsd/nfs4layouts.c
> +++ b/fs/nfsd/nfs4layouts.c
> @@ -136,7 +136,7 @@ void nfsd4_setup_layout_type(struct svc_export *exp)
>  	exp->ex_layout_types |= 1 << LAYOUT_FLEX_FILES;
>  #endif
>  #ifdef CONFIG_NFSD_BLOCKLAYOUT
> -	if (sb->s_export_op->get_uuid &&
> +	if (sb->s_export_op->get_disk_uuid &&
>  	    sb->s_export_op->map_blocks &&
>  	    sb->s_export_op->commit_blocks)
>  		exp->ex_layout_types |= 1 << LAYOUT_BLOCK_VOLUME;
> diff --git a/fs/xfs/xfs_export.c b/fs/xfs/xfs_export.c
> index 201489d3de08..d09570ba7445 100644
> --- a/fs/xfs/xfs_export.c
> +++ b/fs/xfs/xfs_export.c
> @@ -244,7 +244,7 @@ const struct export_operations xfs_export_operations = {
>  	.get_parent		= xfs_fs_get_parent,
>  	.commit_metadata	= xfs_fs_nfs_commit_metadata,
>  #ifdef CONFIG_EXPORTFS_BLOCK_OPS
> -	.get_uuid		= xfs_fs_get_uuid,
> +	.get_disk_uuid		= xfs_fs_get_disk_uuid,
>  	.map_blocks		= xfs_fs_map_blocks,
>  	.commit_blocks		= xfs_fs_commit_blocks,
>  #endif
> diff --git a/fs/xfs/xfs_pnfs.c b/fs/xfs/xfs_pnfs.c
> index afe7497012d4..6ef7b29c4060 100644
> --- a/fs/xfs/xfs_pnfs.c
> +++ b/fs/xfs/xfs_pnfs.c
> @@ -50,7 +50,7 @@ xfs_break_leased_layouts(
>   * the exported device.
>   */
>  int
> -xfs_fs_get_uuid(
> +xfs_fs_get_disk_uuid(
>  	struct super_block	*sb,
>  	u8			*buf,
>  	u32			*len,
> diff --git a/fs/xfs/xfs_pnfs.h b/fs/xfs/xfs_pnfs.h
> index 940c6c2ad88c..df82a6ba1a11 100644
> --- a/fs/xfs/xfs_pnfs.h
> +++ b/fs/xfs/xfs_pnfs.h
> @@ -3,7 +3,7 @@
>  #define _XFS_PNFS_H 1
>  
>  #ifdef CONFIG_EXPORTFS_BLOCK_OPS
> -int xfs_fs_get_uuid(struct super_block *sb, u8 *buf, u32 *len, u64 *offset);
> +int xfs_fs_get_disk_uuid(struct super_block *sb, u8 *buf, u32 *len, u64 *offset);
>  int xfs_fs_map_blocks(struct inode *inode, loff_t offset, u64 length,
>  		struct iomap *iomap, bool write, u32 *device_generation);
>  int xfs_fs_commit_blocks(struct inode *inode, struct iomap *maps, int nr_maps,
> diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
> index 262e24d83313..dc7029949a62 100644
> --- a/include/linux/exportfs.h
> +++ b/include/linux/exportfs.h
> @@ -252,8 +252,10 @@ struct handle_to_path_ctx {
>   * @commit_metadata:
>   *    @commit_metadata should commit metadata changes to stable storage.
>   *
> - * @get_uuid:
> - *    Get a filesystem unique signature exposed to clients.
> + * @get_disk_uuid:
> + *    Get a filesystem unique signature exposed to clients. It's also useful for
> + *    filesystems that support mounting cloned disks and export different UUIDs
> + *    for userspace, while being internally the same.
>   *
>   * @map_blocks:
>   *    Map and, if necessary, allocate blocks for a layout.
> @@ -282,7 +284,7 @@ struct export_operations {
>  	struct dentry * (*get_parent)(struct dentry *child);
>  	int (*commit_metadata)(struct inode *inode);
>  
> -	int (*get_uuid)(struct super_block *sb, u8 *buf, u32 *len, u64 *offset);
> +	int (*get_disk_uuid)(struct super_block *sb, u8 *buf, u32 *len, u64 *offset);
>  	int (*map_blocks)(struct inode *inode, loff_t offset,
>  			  u64 len, struct iomap *iomap,
>  			  bool write, u32 *device_generation);
> 
> -- 
> 2.52.0
> 
> 

Re: [PATCH 1/3] exportfs: Rename get_uuid() to get_disk_uuid()

[Christoph Hellwig]

On Tue, Jan 13, 2026 at 10:10:28PM -0800, Darrick J. Wong wrote:
> On Wed, Jan 14, 2026 at 01:31:41AM -0300, André Almeida wrote:
> > To make clear which UUID is being returned, rename get_uuid() to
> > get_disk_uuid(). Expand the function documentation to note that this
> > function can be also used for filesystem that supports cloned devices
> > that might have different UUIDs for userspace tools, while having the
> > same UUID for internal usage.
> 
> I'm not sure what a "disk uuid" is -- XFS can store two of them in the
> ondisk superblock: the admin-modifiable one that blkid reports, and the
> secret one that's stamped in all the metadata and cannot change.

It isn't.  Totally independent of the rest of the discussion, the
get_uuid exportfs operation is not useful for anything but the original
pNFS block layout.  Which is actually pretty broken and should be slowly
phased out.

> IIRC XFS only shares the user-visible UUID, but they're both from the
> disk.   Also I'm not sure what a non-disk filesystem is supposed to
> provide here?

Yeah.

Re: [PATCH 1/3] exportfs: Rename get_uuid() to get_disk_uuid()

[Amir Goldstein]

On Wed, Jan 14, 2026 at 7:24 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Tue, Jan 13, 2026 at 10:10:28PM -0800, Darrick J. Wong wrote:
> > On Wed, Jan 14, 2026 at 01:31:41AM -0300, André Almeida wrote:
> > > To make clear which UUID is being returned, rename get_uuid() to
> > > get_disk_uuid(). Expand the function documentation to note that this
> > > function can be also used for filesystem that supports cloned devices
> > > that might have different UUIDs for userspace tools, while having the
> > > same UUID for internal usage.
> >
> > I'm not sure what a "disk uuid" is -- XFS can store two of them in the
> > ondisk superblock: the admin-modifiable one that blkid reports, and the
> > secret one that's stamped in all the metadata and cannot change.
>
> It isn't.  Totally independent of the rest of the discussion, the
> get_uuid exportfs operation is not useful for anything but the original
> pNFS block layout.  Which is actually pretty broken and should be slowly
> phased out.
>
> > IIRC XFS only shares the user-visible UUID, but they're both from the
> > disk.   Also I'm not sure what a non-disk filesystem is supposed to
> > provide here?
>
> Yeah.
>

OK. I agree that "disk uuid" is not the best name, but there is a concept
here, which is a uuid that helps to identify the domain of the file handle.

In the context of overlayfs index and "origin" xattr, this is exactly what is
needed - to validate that the object's copy up source is reliable for
the generation of a unique overlayfs object id.

The domain of the file handles is invariant to brtfs clones/snapshots.
Specifically, for btrfs, file handles contain an id of the snapshot,
so the domain of btrfs file handles is logically the uuid of the root fs.

TBH, I am not sure if the file handle domain is invariant to XFS admin
change of uuid. How likely it is to get an identical file handles for two
different objects, with XFS fs which have diverged by an LVM clone?
I think it's quite likely.

Naming is hard - we could maybe use get_domain_uuid() and document
what it means.

Whether or not we should repurpose the existing get_uuid() I don't
know - that depends whether pNFS expects the same UUID from an
"xfs clone" as overlayfs would.

Thanks,
Amir.

Re: [PATCH 1/3] exportfs: Rename get_uuid() to get_disk_uuid()

[Christoph Hellwig]

On Wed, Jan 14, 2026 at 11:12:17AM +0100, Amir Goldstein wrote:
> In the context of overlayfs index and "origin" xattr, this is exactly what is
> needed - to validate that the object's copy up source is reliable for
> the generation of a unique overlayfs object id.

And that's what is in sb->s_uuid.  And it better be persistent.

> TBH, I am not sure if the file handle domain is invariant to XFS admin
> change of uuid. How likely it is to get an identical file handles for two
> different objects, with XFS fs which have diverged by an LVM clone?
> I think it's quite likely.

Of course it is, unlike you explicitly change it using xfs_admin.  Note
that to even mount two clones/snapshots you need to mount with nouuid,
so it doesn't happen accidentally.

> Whether or not we should repurpose the existing get_uuid() I don't
> know - that depends whether pNFS expects the same UUID from an
> "xfs clone" as overlayfs would.

That method does not just return an uuid, but in fact a uniqueue
identifier of the file systems choice and the offset/len where to
look for it on disk, as that is how pnfs/block finds the matching
device.  It is a dangerous concept and should not spread further.

Re: [PATCH 1/3] exportfs: Rename get_uuid() to get_disk_uuid()

[André Almeida]

Em 14/01/2026 07:12, Amir Goldstein escreveu:

[...]

> 
> Whether or not we should repurpose the existing get_uuid() I don't
> know - that depends whether pNFS expects the same UUID from an
> "xfs clone" as overlayfs would.
> 

If we go in that direction, do you think it would be reasonable to have 
this as a super_block member/helper? Also do you know any other fs that 
require this type of workaround on ovl?

Re: [PATCH 1/3] exportfs: Rename get_uuid() to get_disk_uuid()

[Amir Goldstein]

On Wed, Jan 14, 2026 at 5:38 PM André Almeida <andrealmeid@igalia.com> wrote:
>
> Em 14/01/2026 07:12, Amir Goldstein escreveu:
>
> [...]
>
> >
> > Whether or not we should repurpose the existing get_uuid() I don't
> > know - that depends whether pNFS expects the same UUID from an
> > "xfs clone" as overlayfs would.
> >
>
> If we go in that direction, do you think it would be reasonable to have
> this as a super_block member/helper?

IDK. maybe.

> Also do you know any other fs that require this type of workaround on ovl?

Not really.
There are a bunch of fs without UUID for which the mount options
"uuid=off" and "uuid=null" were implemented.
I think we support index with those fs where there is a single lower
layer, so you could use the same trick, but not sure.

Thanks,
Amir.

[PATCH 2/3] btrfs: Implement get_disk_uuid()

[André Almeida]

Every time btrfs mounts a image that it's already mounted (cloned
images), it will assign a new random UUID to it to avoid conflicts.
However, for some internal kernel usage, it's important to access the
original UUID of a given image.

For instance, overlayfs' "index" feature keeps track of the UUID of the
mounted filesystem on it's upper layer, to avoid being remounted with a
different filesystem. However, overlayfs uses the same random UUID
exposed to userspace, so the "index" check will fail when trying to
remount the very same filesystem.

Implement export operation get_disk_uuid() to export the real image
UUID.

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

diff --git a/fs/btrfs/export.c b/fs/btrfs/export.c
index 230d9326b685..09f9ef8c1b1e 100644
--- a/fs/btrfs/export.c
+++ b/fs/btrfs/export.c
@@ -8,6 +8,7 @@
 #include "export.h"
 #include "accessors.h"
 #include "super.h"
+#include "volumes.h"
 
 #define BTRFS_FID_SIZE_NON_CONNECTABLE (offsetof(struct btrfs_fid, \
 						 parent_objectid) / 4)
@@ -298,10 +299,29 @@ static int btrfs_get_name(struct dentry *parent, char *name,
 	return 0;
 }
 
+static int btrfs_get_disk_uuid(struct super_block *sb, u8 *buf, u32 *len,
+			       u64 *offset)
+{
+	struct btrfs_fs_devices *fs_dev = btrfs_sb(sb)->fs_devices;
+
+	if (fs_dev->temp_fsid)
+		return -ENODATA;
+
+	if (*len < sizeof(uuid_t))
+		return -EINVAL;
+
+	memcpy(buf, &fs_dev->metadata_uuid, sizeof(uuid_t));
+	*offset = offsetof(struct btrfs_fs_devices, metadata_uuid);
+	*len = sizeof(uuid_t);
+
+	return 0;
+}
+
 const struct export_operations btrfs_export_ops = {
 	.encode_fh	= btrfs_encode_fh,
 	.fh_to_dentry	= btrfs_fh_to_dentry,
 	.fh_to_parent	= btrfs_fh_to_parent,
 	.get_parent	= btrfs_get_parent,
 	.get_name	= btrfs_get_name,
+	.get_disk_uuid  = btrfs_get_disk_uuid,
 };

-- 
2.52.0

[PATCH 3/3] ovl: Use real disk UUID for origin file handles

[André Almeida]

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

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Christoph Hellwig]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[André Almeida]

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?

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

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

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Qu Wenruo]

在 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

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

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

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

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Qu Wenruo]

在 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

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Christoph Hellwig]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[André Almeida]

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

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Amir Goldstein]

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/

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[André Almeida]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Christoph Hellwig]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Amir Goldstein]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[André Almeida]

[+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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Amir Goldstein]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[André Almeida]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Amir Goldstein]

[-- Attachment #1: Type: text/plain, Size: 7394 bytes --]

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.

[-- Attachment #2: 0001-ovl-relax-requirement-for-uuid-off-index-on.patch --]
[-- Type: text/x-patch, Size: 5560 bytes --]

From 147e88d88b5dfbcdd23aff736e4d381a8af446f6 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il@gmail.com>
Date: Tue, 20 Jan 2026 15:58:31 +0100
Subject: [PATCH] ovl: relax requirement for uuid=off,index=on

uuid=off,index=on required that all upper/lower directories are on the
same filesystem.

Relax the requirement so that only all the lower directories need to be
on the same filesystem.

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 Documentation/filesystems/overlayfs.rst |  2 +-
 fs/overlayfs/namei.c                    | 21 +++++++++++++--------
 fs/overlayfs/overlayfs.h                |  2 ++
 fs/overlayfs/super.c                    | 13 +++++--------
 4 files changed, 21 insertions(+), 17 deletions(-)

diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
index ab989807a2cb6..d4020eae1deba 100644
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -755,7 +755,7 @@ 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
 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.
 
 
diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
index e9a69c95be918..74c514603ac23 100644
--- a/fs/overlayfs/namei.c
+++ b/fs/overlayfs/namei.c
@@ -158,6 +158,18 @@ static struct ovl_fh *ovl_get_fh(struct ovl_fs *ofs, struct dentry *upperdentry,
 	goto out;
 }
 
+bool ovl_uuid_match(struct ovl_fs *ofs, const struct super_block *sb,
+		    const uuid_t *uuid)
+{
+	/*
+	 * Make sure that the stored uuid matches the uuid of the lower
+	 * layer where file handle will be decoded.
+	 * In case of uuid=off option just make sure that stored uuid is null.
+	 */
+	return ovl_origin_uuid(ofs) ? uuid_equal(uuid, &sb->s_uuid) :
+				      uuid_is_null(uuid);
+}
+
 struct dentry *ovl_decode_real_fh(struct ovl_fs *ofs, struct ovl_fh *fh,
 				  struct vfsmount *mnt, bool connected)
 {
@@ -167,14 +179,7 @@ struct dentry *ovl_decode_real_fh(struct ovl_fs *ofs, struct ovl_fh *fh,
 	if (!capable(CAP_DAC_READ_SEARCH))
 		return NULL;
 
-	/*
-	 * Make sure that the stored uuid matches the uuid of the lower
-	 * layer where file handle will be decoded.
-	 * In case of uuid=off option just make sure that stored uuid is null.
-	 */
-	if (ovl_origin_uuid(ofs) ?
-	    !uuid_equal(&fh->fb.uuid, &mnt->mnt_sb->s_uuid) :
-	    !uuid_is_null(&fh->fb.uuid))
+	if (!ovl_uuid_match(ofs, mnt->mnt_sb, &fh->fb.uuid))
 		return NULL;
 
 	bytes = (fh->fb.len - offsetof(struct ovl_fb, fid));
diff --git a/fs/overlayfs/overlayfs.h b/fs/overlayfs/overlayfs.h
index f9ac9bdde8305..cf10661522106 100644
--- a/fs/overlayfs/overlayfs.h
+++ b/fs/overlayfs/overlayfs.h
@@ -710,6 +710,8 @@ static inline int ovl_check_fh_len(struct ovl_fh *fh, int fh_len)
 	return ovl_check_fb_len(&fh->fb, fh_len - OVL_FH_WIRE_OFFSET);
 }
 
+bool ovl_uuid_match(struct ovl_fs *ofs, const struct super_block *sb,
+		    const uuid_t *uuid);
 struct dentry *ovl_decode_real_fh(struct ovl_fs *ofs, struct ovl_fh *fh,
 				  struct vfsmount *mnt, bool connected);
 int ovl_check_origin_fh(struct ovl_fs *ofs, struct ovl_fh *fh, bool connected,
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index ba9146f22a2cc..8f0ecb4905e93 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -940,7 +940,7 @@ static bool ovl_lower_uuid_ok(struct ovl_fs *ofs, const uuid_t *uuid)
 		 * disable lower file handle decoding on all of them.
 		 */
 		if (ofs->fs[i].is_lower &&
-		    uuid_equal(&ofs->fs[i].sb->s_uuid, uuid)) {
+		    ovl_uuid_match(ofs, ofs->fs[i].sb, uuid)) {
 			ofs->fs[i].bad_uuid = true;
 			return false;
 		}
@@ -952,6 +952,7 @@ static bool ovl_lower_uuid_ok(struct ovl_fs *ofs, const uuid_t *uuid)
 static int ovl_get_fsid(struct ovl_fs *ofs, const struct path *path)
 {
 	struct super_block *sb = path->mnt->mnt_sb;
+	const uuid_t *uuid = ovl_origin_uuid(ofs) ? &sb->s_uuid : &uuid_null;
 	unsigned int i;
 	dev_t dev;
 	int err;
@@ -963,7 +964,7 @@ static int ovl_get_fsid(struct ovl_fs *ofs, const struct path *path)
 			return i;
 	}
 
-	if (!ovl_lower_uuid_ok(ofs, &sb->s_uuid)) {
+	if (!ovl_lower_uuid_ok(ofs, uuid)) {
 		bad_uuid = true;
 		if (ofs->config.xino == OVL_XINO_AUTO) {
 			ofs->config.xino = OVL_XINO_OFF;
@@ -976,8 +977,7 @@ static int ovl_get_fsid(struct ovl_fs *ofs, const struct path *path)
 		}
 		if (warn) {
 			pr_warn("%s uuid detected in lower fs '%pd2', falling back to xino=%s,index=off,nfs_export=off.\n",
-				uuid_is_null(&sb->s_uuid) ? "null" :
-							    "conflicting",
+				uuid_is_null(uuid) ? "null" : "conflicting",
 				path->dentry, ovl_xino_mode(&ofs->config));
 		}
 	}
@@ -1469,10 +1469,7 @@ static int ovl_fill_super_creds(struct fs_context *fc, struct super_block *sb)
 	if (!ovl_upper_mnt(ofs))
 		sb->s_flags |= SB_RDONLY;
 
-	if (!ovl_origin_uuid(ofs) && ofs->numfs > 1) {
-		pr_warn("The uuid=off requires a single fs for lower and upper, falling back to uuid=null.\n");
-		ofs->config.uuid = OVL_UUID_NULL;
-	} else if (ovl_has_fsid(ofs) && ovl_upper_mnt(ofs)) {
+	if (ovl_has_fsid(ofs) && ovl_upper_mnt(ofs)) {
 		/* Use per instance persistent uuid/fsid */
 		ovl_init_uuid_xattr(sb, ofs, &ctx->upper);
 	}
-- 
2.52.0

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Amir Goldstein]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[André Almeida]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[André Almeida]

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é

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Amir Goldstein]

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

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Amir Goldstein]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[André Almeida]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Amir Goldstein]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[André Almeida]

Em 06/02/2026 10:12, Amir Goldstein escreveu:
> On Thu, Feb 5, 2026 at 9:34 PM André Almeida <andrealmeid@igalia.com> wrote:
>>
>> 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.
> 

Hi Amir,

I can confirm that this is useful for my workload. After correctly 
setting this flag for every mount, everything is working good and we can 
bypass the random UUID issues. Thank you for your help!

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Amir Goldstein]

On Mon, Feb 16, 2026 at 4:59 PM André Almeida <andrealmeid@igalia.com> wrote:
>
> Em 06/02/2026 10:12, Amir Goldstein escreveu:
> > On Thu, Feb 5, 2026 at 9:34 PM André Almeida <andrealmeid@igalia.com> wrote:
> >>
> >> 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.
> >
>
> Hi Amir,
>
> I can confirm that this is useful for my workload. After correctly
> setting this flag for every mount, everything is working good and we can
> bypass the random UUID issues. Thank you for your help!

OK, PR sent.

Thanks,
Amir.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Christoph Hellwig]

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.

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Amir Goldstein]

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/

Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[Christoph Hellwig]

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.