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
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
>
>
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.
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.
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?
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.
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.
© 2016 - 2026 Red Hat, Inc.