[PATCH 0/3] fix s_uuid and f_fsid consistency for cloned filesystems

[PATCH 0/3] fix s_uuid and f_fsid consistency for cloned filesystems

[Anand Jain]

Btrfs, XFS and ext4 currently handle s_uuid and f_fsid differently when
a filesystem is cloned (e.g. snapshot or block-level copy), leading to
inconsistent behaviour across filesystems.

The table below summarises the current and post-patch behaviour.
"same" means the value is identical on both the original and cloned
filesystem.

Cloned filesystem:

              | s_uuid  f_fsid
--------------|---------------------------
EXT4          | same    same
Btrfs         | random  random
XFS           | same    f(devt)
EXT4-patched  | same    f(devt)
Btrfs-patched | same    f(s_uuid,rootid,devt)

Problem
-------
Btrfs currently never duplicates s_uuid or f_fsid for cloned filesystems.
When an fsid collision is detected at mount time, btrfs generates a new
in-memory fsid (temp_fsid), but this is ephemeral — it changes on every
mount. This has two consequences:

1. IMA (Integrity Measurement Architecture) cannot reliably track the
   filesystem across mount-cycle, since the f_fsid it sees keeps changing.
   This does not scale. Whereas on the otherhand if you have same s_uuid
   on multiple filesystems, monitoring per distint filesystem is lost.

2. If we instead allow cloned filesystems to share the same f_fsid (as
   ext4 currently does), fanotify loses the ability to distinguish
   between distinct filesystem instances. FAN_EVENT_INFO_TYPE_FID events
   will fail to resolve to the correct mountpoint when f_fsid values
   are identical across clones.

This series resolves the tradeoff by aligning btrfs and ext4 behaviour
with XFS: f_fsid incorporates device identity (devt) to remain unique
across clones, while s_uuid is preserved consistently matching the on-disk
uuid.

Patches
-------
Patch 1/3: btrfs: fix f_fsid to include rootid and devt
Patch 2/3: btrfs: fix s_uuid to be stable across mounts for cloned filesystems  
Patch 3/3: ext4: fix f_fsid to use devt instead of s_uuid

Anand Jain (3):
  btrfs: derive f_fsid from on-disk fsuuid and dev_t
  btrfs: use on-disk uuid for s_uuid in temp_fsid mounts
  ext4: derive f_fsid from block device to avoid collisions

 fs/btrfs/disk-io.c |  3 ++-
 fs/btrfs/super.c   | 27 +++++++++++++++++++++++----
 fs/ext4/super.c    |  2 +-
 3 files changed, 26 insertions(+), 6 deletions(-)

-- 
2.43.0

[PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t

[Anand Jain]

Currently, f_fsid depends on fs_devices->fsid. For cloned devices, this
value is dynamic and fluctuates across mount cycles. This inconsistency
breaks persistence for subsystems like IMA.

Switch to a stable derivation using the persistent on-disk fsuuid +
root id + devt of the block device for the single device filesystem.
This is consistent as long as the device remains unchanged/replace
(excludes btrfs device replace secnario for now).

Signed-off-by: Anand Jain <asj@kernel.org>
---
 fs/btrfs/super.c | 27 +++++++++++++++++++++++----
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 125fca57c164..68473663fe1e 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1733,7 +1733,7 @@ static int btrfs_statfs(struct dentry *dentry, struct kstatfs *buf)
 	u64 total_free_data = 0;
 	u64 total_free_meta = 0;
 	u32 bits = fs_info->sectorsize_bits;
-	__be32 *fsid = (__be32 *)fs_info->fs_devices->fsid;
+	__be32 *fsid;
 	unsigned factor = 1;
 	struct btrfs_block_rsv *block_rsv = &fs_info->global_block_rsv;
 	int ret;
@@ -1819,15 +1819,34 @@ static int btrfs_statfs(struct dentry *dentry, struct kstatfs *buf)
 	buf->f_bsize = fs_info->sectorsize;
 	buf->f_namelen = BTRFS_NAME_LEN;
 
-	/* We treat it as constant endianness (it doesn't matter _which_)
-	   because we want the fsid to come out the same whether mounted
-	   on a big-endian or little-endian host */
+	/*
+	 * fs_devices->fsid is dynamically generated when temp_fsid is active
+	 * to support cloned devices. Use the original on-disk fsid instead,
+	 * as it remains consistent across mount cycles.
+	 */
+	fsid = (__be32 *)fs_info->super_copy->fsid;
+	/*
+	 * We treat it as constant endianness (it doesn't matter _which_)
+	 * because we want the fsid to come out the same whether mounted
+	 * on a big-endian or little-endian host.
+	 */
 	buf->f_fsid.val[0] = be32_to_cpu(fsid[0]) ^ be32_to_cpu(fsid[2]);
 	buf->f_fsid.val[1] = be32_to_cpu(fsid[1]) ^ be32_to_cpu(fsid[3]);
 	/* Mask in the root object ID too, to disambiguate subvols */
 	buf->f_fsid.val[0] ^= btrfs_root_id(BTRFS_I(d_inode(dentry))->root) >> 32;
 	buf->f_fsid.val[1] ^= btrfs_root_id(BTRFS_I(d_inode(dentry))->root);
 
+	/*
+	 * dev_t provides way to differentiate mounted cloned devices keeps
+	 * the statfs fid is consistent and unique.
+	 */
+	if (fs_info->fs_devices->total_devices == 1) {
+		__kernel_fsid_t dev_fsid = \
+	u64_to_fsid(huge_encode_dev(fs_info->fs_devices->latest_dev->bdev->bd_dev));
+		buf->f_fsid.val[0] ^= dev_fsid.val[1];
+		buf->f_fsid.val[1] ^= dev_fsid.val[0];
+	}
+
 	return 0;
 }
 
-- 
2.43.0

[PATCH 2/3] btrfs: use on-disk uuid for s_uuid in temp_fsid mounts

[Anand Jain]

When mounting a cloned filesystem with a temporary fsuuid (temp_fsid),
layered modules like overlayfs require a persistent identifier.

While internal in-memory fs_devices->fsid must remain dynamic to
distinguish the clone from the source, s_uuid should reflect the
original on-disk UUID to provide consistency for upper-layer consumers.

Signed-off-by: Anand Jain <asj@kernel.org>
---
 fs/btrfs/disk-io.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 15c4fdaff3de..98387516ef5b 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3443,7 +3443,8 @@ int __cold open_ctree(struct super_block *sb, struct btrfs_fs_devices *fs_device
 	/* Update the values for the current filesystem. */
 	sb->s_blocksize = sectorsize;
 	sb->s_blocksize_bits = blksize_bits(sectorsize);
-	memcpy(&sb->s_uuid, fs_info->fs_devices->fsid, BTRFS_FSID_SIZE);
+	/* Copy on-disk uuid, even for temp_fsid mounts */
+	memcpy(&sb->s_uuid, fs_info->super_copy->fsid, BTRFS_FSID_SIZE);
 
 	mutex_lock(&fs_info->chunk_mutex);
 	ret = btrfs_read_sys_array(fs_info);
-- 
2.43.0

Re: [PATCH 0/3] fix s_uuid and f_fsid consistency for cloned filesystems

[Christoph Hellwig]

On Thu, Feb 26, 2026 at 10:23:32PM +0800, Anand Jain wrote:
> This series resolves the tradeoff by aligning btrfs and ext4 behaviour
> with XFS: f_fsid incorporates device identity (devt) to remain unique
> across clones, while s_uuid is preserved consistently matching the on-disk
> uuid.

While I like fixing this up, switching the f_fsid construction to a
different method might break things.  Is there a way to only change
it for cloned file systems to reduce the surface of this change?

> Patches
> -------
> Patch 1/3: btrfs: fix f_fsid to include rootid and devt
> Patch 2/3: btrfs: fix s_uuid to be stable across mounts for cloned filesystems  
> Patch 3/3: ext4: fix f_fsid to use devt instead of s_uuid

I don't really see that patch 3 in my inbox on linux-btrfs.

Re: [PATCH 0/3] fix s_uuid and f_fsid consistency for cloned filesystems

[Anand Jain]

On 4/3/26 21:28, Christoph Hellwig wrote:
> On Thu, Feb 26, 2026 at 10:23:32PM +0800, Anand Jain wrote:
>> This series resolves the tradeoff by aligning btrfs and ext4 behaviour
>> with XFS: f_fsid incorporates device identity (devt) to remain unique
>> across clones, while s_uuid is preserved consistently matching the on-disk
>> uuid.
> 
> While I like fixing this up, switching the f_fsid construction to a
> different method might break things.  Is there a way to only change
> it for cloned file systems to reduce the surface of this change?

The problem is that we won't know which filesystem is the original
and which is the clone. Generally, the first one mounted is treated
as the original and the following one as the clone. However, f_fsid
should remain consistent regardless of mount order, at least for
the duration that the block device is connected (or until a
system reboot).

>> Patches
>> -------
>> Patch 1/3: btrfs: fix f_fsid to include rootid and devt
>> Patch 2/3: btrfs: fix s_uuid to be stable across mounts for cloned filesystems  
>> Patch 3/3: ext4: fix f_fsid to use devt instead of s_uuid
> 
> I don't really see that patch 3 in my inbox on linux-btrfs.


My bad, I sent the btrfs/ext4 patches only to their respective
mailing lists. I'll copy both in v2.

Here it is:

 https://lore.kernel.org/linux-ext4/e269a49eed2de23eb9f9bd7f506f0fe47696a023.1772095546.git.asj@kernel.org/


Thanks, Anand

Re: [PATCH 0/3] fix s_uuid and f_fsid consistency for cloned filesystems

[Christoph Hellwig]

On Thu, Mar 05, 2026 at 05:32:36PM +0800, Anand Jain wrote:
> The problem is that we won't know which filesystem is the original
> and which is the clone. Generally, the first one mounted is treated
> as the original and the following one as the clone. However, f_fsid
> should remain consistent regardless of mount order, at least for
> the duration that the block device is connected (or until a
> system reboot).

Then maybe we need to make the new sane behavior dependent on a
feature flag so that only newly created file systems use it?

Re: [PATCH 0/3] fix s_uuid and f_fsid consistency for cloned filesystems

[Theodore Tso]

On Thu, Feb 26, 2026 at 10:23:32PM +0800, Anand Jain wrote:
> 
>               | s_uuid  f_fsid
> --------------|---------------------------
> EXT4          | same    same
> Btrfs         | random  random
> XFS           | same    f(devt)
> EXT4-patched  | same    f(devt)
> Btrfs-patched | same    f(s_uuid,rootid,devt)

I don't *object* to changing ext4 reports since having something that
is unique is probably better.  However, my bigger concern is using
f_fsid in the first place.  It's only 64 bits, and that's really not
enough to gaurantee uniqueness.  And even as you've proposed to change
things, it's not consistent across file systems.  In particular, your
proposed solution mixes s_uuid into btrfs-patched, but not
ext4-patched.  Why?

> Problem
> -------
> Btrfs currently never duplicates s_uuid or f_fsid for cloned filesystems.
> When an fsid collision is detected at mount time, btrfs generates a new
> in-memory fsid (temp_fsid), but this is ephemeral — it changes on every
> mount. This has two consequences:
> 
> 1. IMA (Integrity Measurement Architecture) cannot reliably track the
>    filesystem across mount-cycle, since the f_fsid it sees keeps changing.
>    This does not scale. Whereas on the otherhand if you have same s_uuid
>    on multiple filesystems, monitoring per distint filesystem is lost.

The problem with using f(dev_t) for IMA is that if you have a
removable device (e.g., an SD card), reporting f_fsid as purely being
a function of dev_t means that the if an SD card ejected, and replaced
with another, the fsid_t will manifestly *not* be unique.  So in that
sense, replace f(dev_t) with f(s_uuid) would be worse if you think
"file system unique id" should be unique in the case of removable
storage devices.

If the audit log includes mounts and unmounts, then this might not be
fatal.  But if less-than intelligent system administrator or LLM tries
to analyize an audit log using tools like "grep", it would be pretty
easy for someone to get misled.

I know you were primarily interested in cloned file systems, but I
think we also need to take into account other cases, including ones
where there might be more the file system associated with a block
device over time.

> 2. If we instead allow cloned filesystems to share the same f_fsid (as
>    ext4 currently does), fanotify loses the ability to distinguish
>    between distinct filesystem instances. FAN_EVENT_INFO_TYPE_FID events
>    will fail to resolve to the correct mountpoint when f_fsid values
>    are identical across clones.

My personal opinion is that f_fsuid is just a terrible interface, the
fact that IMA and fanotify used this is regrettable.  I understand why
it happened, because there wasn't anything better, and for many use
cases, it's good enough.   But not all.

So I hope we can just actively discourage anyone else using it.  Given
that exactly it has not been standardized, across different operating
systems, and different file systems for Linux --- hopefully most
people will have already made that choice.

						- Ted