fix s_uuid and f_fsid consistency for cloned filesystems
Subsystems (2)
cover fix s_uuid and f_fsid consistency for cloned filesystems
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(-)
Signature · 1 line
2.43.0
PATCH 1/3 btrfs: derive f_fsid from on-disk fsuuid and dev_t
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).
--- fs/btrfs/super.c | 27 +++++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-)
fs/btrfs/super.c +23 -4
@@ -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 ; }
Signature · 1 line
2.43.0
Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t
Quoted 8 lines · Anand Jain
Currently,
f_fsiddepends onfs_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).
This commit evidently hit 7.2 and is causing end users some real pain. Real software uses the FSID to encrypt/decrypt their VPN key files:
https://github.com/NetworkManager/NetworkManager-openconnect/
When this gets applied, those users suddenly can't connect to their VPN any more. Having a stable derivation does seem like a good idea, of course. Is there any way to make this transition without breaking existing userspace and existing users?
It looks like this is also getting -stable backports.
Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t
Quoted 13 lines · Dave Hansen
Quoted 8 lines · Anand Jain
Currently,
f_fsiddepends onfs_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).
This commit evidently hit 7.2 and is causing end users some real pain. Real software uses the FSID to encrypt/decrypt their VPN key files:
Quoted 10 lines
https://github.com/NetworkManager/NetworkManager-openconnect/
When this gets applied, those users suddenly can't connect to their VPN any more. Having a stable derivation does seem like a good idea, of course. Is there any way to make this transition without breaking existing userspace and existing users?
It looks like this is also getting -stable backports.
Dave,
Thanks for the report.
I wish I had more clarity on how OpenConnect uses the FSID before I comment. Do you know? Can you shed some light on this?
Also, a couple of quick checks:
Is the underlying device MAJ:MIN changing before and after the upgrade?
Are the original and cloned Btrfs filesystems mounted simultaneously?
Patch v3 (1/2) keeps the FSID persistent from the on-disk superblock and stops exposing the internal random FSID. However, if OpenConnect relies on statfs.f_fsid, patch v3 (2/2) now derives f_fsid from the underlying MAJ:MIN.
Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t
Quoted 2 lines · On Friday, 11 September 2026 07:51:16 Pacific Daylight Time Anand Suveer Jain…
I wish I had more clarity on how OpenConnect uses the FSID before I comment. Do you know? Can you shed some light on this?
It's openconnect's option --key-password-from-fsid. It uses the FSID encoded in hex format as the key's passphrase.
To reproduce, take any key without a password and do:
openssl rsa -in unencrypted-key.pem -out encrypted-key.pem
And paste your FSID as the password.
This is not real security, we all agree. David W can probably remember better why this option exists, but I would suspect it was an IT mandate that a) the key not be left unencrypted on disk and b) be specific to a given machine, avoiding reuse by being copied to another. Ideally, we'd use TPM these days, but there are still a lot of systems without it where Linux runs, and especially a lot of legacy set ups.
But very simply, it's the fact that the FSID has been used as a stable identifier and no longer is if the device in question is not itself stable.
Quoted 3 lines
Also, a couple of quick checks:
Is the underlying device MAJ:MIN changing before and after the upgrade?
Unknown. It's LVM and I don't know if the order of activation of LVs is guaranteed. I wouldn't rely on it. I'll tell you next time I reboot if the order is the same as this:
brw-rw---- 1 root disk 254, 0 Sep 7 20:28 cr-auto-1 brw-rw---- 1 root disk 254, 1 Sep 7 20:28 system-root brw-rw---- 1 root disk 254, 2 Sep 7 20:28 system-swap brw-rw---- 1 root disk 254, 3 Sep 7 20:28 system-pool_tmeta brw-rw---- 1 root disk 254, 4 Sep 7 20:28 system-pool_tdata brw-rw---- 1 root disk 254, 5 Sep 7 20:28 system-pool-tpool brw-rw---- 1 root disk 254, 6 Sep 7 20:28 system-pool brw-rw---- 1 root disk 254, 7 Sep 7 20:28 system-stuff brw-rw---- 1 root disk 254, 8 Sep 7 20:28 system-home brw-rw---- 1 root disk 254, 9 Sep 7 20:28 system-stuff2
Either way, the point is that it changed from 7.1 when the MAJ:MIN was not mixed in.
Quoted 1 line
Are the original and cloned Btrfs filesystems mounted simultaneously?
No cloning is involved.
Quoted 4 lines
Patch v3 (1/2) keeps the FSID persistent from the on-disk superblock and stops exposing the internal random FSID. However, if OpenConnect relies on statfs.f_fsid, patch v3 (2/2) now derives
f_fsidfrom the underlying MAJ:MIN.
Signature · 2 lines
Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCG - Platform & Sys. Eng.
Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t
Quoted 19 lines · Thiago Macieira
Quoted 2 lines · On Friday, 11 September 2026 07:51:16 Pacific Daylight Time Anand Suveer Jain…
I wish I had more clarity on how OpenConnect uses the FSID before I comment. Do you know? Can you shed some light on this?
It's openconnect's option --key-password-from-fsid. It uses the FSID encoded in hex format as the key's passphrase.
To reproduce, take any key without a password and do:
openssl rsa -in unencrypted-key.pem -out encrypted-key.pem
And paste your FSID as the password.This is not real security, we all agree. David W can probably remember better why this option exists, but I would suspect it was an IT mandate that a) the key not be left unencrypted on disk and b) be specific to a given machine, avoiding reuse by being copied to another. Ideally, we'd use TPM these days, but there are still a lot of systems without it where Linux runs, and especially a lot of legacy set ups.
Quoted 2 lines
But very simply, it's the fact that the FSID has been used as a stable identifier and no longer is if the device in question is not itself stable.
Right. This was never "security" per se.
In the early days of OpenConnect we were required by Intel IT to match the level of security of the Windows key store. Which basically meant that it would not prevent an *attacker* but would prevent a genuine user who hasn't read (or chooses not to obey) the security policy and wants to copy certificates from one machine to another... for at least five minutes (downloading Jailbreak, in the Windows case, and re-encrying the key, in the Linux case).
It's not high security but it *does* mean that a key file can't *trivially* be copied from machine to machine. Or recovered in useable form from a backup.
Encrypting it with the FSID of the file system it's stored on did a reasonable job of what it was intended to achieve. And the FSID is supposed to be *stable* and not break on a kernel upgrade. (Isn't it part of the NHS FH too, or is that derived entirely differently?)
Of course, you *should* have moved on to using a TPM by now; I don't buy the excuse that it isn't available. But still, the kernel shouldn't break userspace *even* if you deserve it for still using this hack in 2026.
Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t
Quoted 20 lines · David Woodhouse
Quoted 19 lines · Thiago Macieira
Quoted 2 lines · On Friday, 11 September 2026 07:51:16 Pacific Daylight Time Anand Suveer Jain…
I wish I had more clarity on how OpenConnect uses the FSID before I comment. Do you know? Can you shed some light on this?
It's openconnect's option --key-password-from-fsid. It uses the FSID encoded in hex format as the key's passphrase.
To reproduce, take any key without a password and do:
openssl rsa -in unencrypted-key.pem -out encrypted-key.pem
And paste your FSID as the password.This is not real security, we all agree. David W can probably remember better why this option exists, but I would suspect it was an IT mandate that a) the key not be left unencrypted on disk and b) be specific to a given machine, avoiding reuse by being copied to another. Ideally, we'd use TPM these days, but there are still a lot of systems without it where Linux runs, and especially a lot of legacy set ups.
Quoted 9 lines
Quoted 2 lines
But very simply, it's the fact that the FSID has been used as a stable identifier and no longer is if the device in question is not itself stable.
Right. This was never "security" per se.
In the early days of OpenConnect we were required by Intel IT to match the level of security of the Windows key store. Which basically meant that it would not prevent an *attacker* but would prevent a genuine user who hasn't read (or chooses not to obey) the security policy and wants to copy certificates from one machine to another... for at least five minutes (downloading Jailbreak, in the Windows case, and re-encrying the key, in the Linux case).
It's not high security but it *does* mean that a key file can't *trivially* be copied from machine to machine. Or recovered in useable form from a backup.
Got it.
Quoted 2 lines
Encrypting it with the FSID of the file system it's stored on did a reasonable job of what it was intended to achieve. And the FSID is supposed to be *stable* and not break on a kernel upgrade. (Isn't it part of the NHS FH too, or is that derived entirely differently?)
Are you referring to NFS file handles? That already works fine for non-cloned Btrfs. The whole point of this patch was to keep fsid consistent across mounts for cloned filesystems too, but it turned out to break backward compatibility for the original filesystem.
Besides, I don't think your approach works with XFS or F2FS either or at least it hasn't been tested with dynamic disk discovery? Both of those derive fsid from dev_t MAJ:MIN, which isn't guaranteed to stay stable across reboots.
Quoted 1 line
Of course, you *should* have moved on to using a TPM by now; I don't buy the excuse that it isn't available. But still, the kernel shouldn't break userspace *even* if you deserve it for still using this hack in 2026.
Fair point the patch definitely isn't ready for Stable kernel as-is. I'll get a backport-friendly fix out asap.
Thanks
Anand
Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t
In reply to Anand Suveer JainQuoted 29 lines · Anand Suveer Jain
Quoted 13 lines · Dave Hansen
Quoted 8 lines · Anand Jain
Currently,
f_fsiddepends onfs_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).
This commit evidently hit 7.2 and is causing end users some real pain. Real software uses the FSID to encrypt/decrypt their VPN key files:
Quoted 8 lines
https://github.com/NetworkManager/NetworkManager-openconnect/
When this gets applied, those users suddenly can't connect to their VPN any more. Having a stable derivation does seem like a good idea, of course. Is there any way to make this transition without breaking existing userspace and existing users?
It looks like this is also getting -stable backports.
I wish I had more clarity on how OpenConnect uses the FSID before I comment. Do you know? Can you shed some light on this?
Also, a couple of quick checks:
Quoted 8 lines
Is the underlying device MAJ:MIN changing before and after the upgrade?
Are the original and cloned Btrfs filesystems mounted simultaneously?
Patch v3 (1/2) keeps the FSID persistent from the on-disk superblock and stops exposing the internal random FSID. However, if OpenConnect relies on statfs.f_fsid, patch v3 (2/2) now derives
f_fsidfrom the underlying MAJ:MIN.
You've sent the fsid patches [1] to fix some IMA and fanotify problems, so I guess there's a use case. This report shows a clear breakage in a different use case, I'm thinking about a quick revert as it seems to have worse consequences. A fix to make both work would be good but I can't estimate when it'll be ready so for now I'd go for a revert and then forward it to 7.2 stable tree.
Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t
Quoted 39 lines · David Sterba
Quoted 29 lines · Anand Suveer Jain
Quoted 13 lines · Dave Hansen
Quoted 8 lines · Anand Jain
Currently,
f_fsiddepends onfs_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).
This commit evidently hit 7.2 and is causing end users some real pain. Real software uses the FSID to encrypt/decrypt their VPN key files:
Quoted 8 lines
https://github.com/NetworkManager/NetworkManager-openconnect/
When this gets applied, those users suddenly can't connect to their VPN any more. Having a stable derivation does seem like a good idea, of course. Is there any way to make this transition without breaking existing userspace and existing users?
It looks like this is also getting -stable backports.
I wish I had more clarity on how OpenConnect uses the FSID before I comment. Do you know? Can you shed some light on this?
Also, a couple of quick checks:
Quoted 8 lines
Is the underlying device MAJ:MIN changing before and after the upgrade?
Are the original and cloned Btrfs filesystems mounted simultaneously?
Patch v3 (1/2) keeps the FSID persistent from the on-disk superblock and stops exposing the internal random FSID. However, if OpenConnect relies on statfs.f_fsid, patch v3 (2/2) now derives
f_fsidfrom the underlying MAJ:MIN.
Quoted 8 lines
You've sent the fsid patches [1] to fix some IMA and fanotify problems, so I guess there's a use case. This report shows a clear breakage in a different use case, I'm thinking about a quick revert as it seems to have worse consequences. A fix to make both work would be good but I can't estimate when it'll be ready so for now I'd go for a revert and then forward it to 7.2 stable tree.
Dave,
I'm currently testing the changes below, which limit the new fsid behavior (deriving it from dev_t) strictly to cloned Btrfs.
If all goes well, I'll post the patch or will update how it goes by EOD . Thanks!
------------
fs/btrfs/super.c +0 -0
@@ -1836,8 +1836,12 @@ static int btrfs_statfs(struct dentry *dentry,
struct kstatfs *buf)
f_fsid.val[0] ^= btrfs_root_id(BTRFS_I(d_inode(dentry))->root)
Quoted 1 line
Quoted 1 line
32;
f_fsid.val[1] ^= btrfs_root_id(BTRFS_I(d_inode(dentry))->root);
- /* Hash dev_t to avoid f_fsid collision with cloned filesystems. */
- if (fs_info->fs_devices->total_devices == 1) {
+ /*
+ * Hash dev_t to avoid f_fsid collisions with cloned filesystems.
+ * Only do this when a clone is present so the original filesystem
+ * (mounted first) maintains backward-compatible f_fsid behavior.
+ */+ if (fs_info->fs_devices->temp_fsid) {
__kernel_fsid_t dev_fsid =
u64_to_fsid(huge_encode_dev(fs_info->fs_devices->latest_dev->bdev->bd_dev));
Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t
Quoted 7 lines · Anand Suveer Jain
fs/btrfs/super.c +0
-0@@ -1836,8 +1836,12 @@ static int btrfs_statfs(struct dentry *dentry, struct kstatfs *buf) f_fsid.val[0] ^= btrfs_root_id(BTRFS_I(d_inode(dentry))->root) >> 32; f_fsid.val[1 ] ^=btrfs_root_id (BTRFS_I (d_inode (dentry))->root);
fs/btrfs/super.c static int btrfs_statfs(struct dentry *dentry, · line 1847
Quoted 10 lines
fs/btrfs/super.c +6
-2-/* Hash dev_t to avoid f_fsid collision with cloned filesystems. */ -if (fs_info->fs_devices->total_devices ==1 ) { +/* +* Hash dev_t to avoid f_fsid collisions with cloned filesystems. +* Only do this when a clone is present so the original filesystem +* (mounted first) maintains backward-compatible f_fsid behavior. +*/ +if (fs_info->fs_devices->temp_fsid) { __kernel_fsid_t dev_fsid =
This should fix the most common case where people don't have any cloned filesystems at all, so I guess this is good as a fix. Please send it so I can add it to this -rc pull request. We can try to catch next week's release of stable trees.
Related to the cloned filesystems, it can get complicated if the original filesystem gets unmounted and mounted again, now it would have the temp_fsid set, right?
I don't see the temp_fsid documented (btrfs-progs) other than in the changelogs and briefly in the sysfs file. This should be more visible as a separate feature and with the known use cases.
Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t
Quoted 21 lines · David Sterba
Quoted 7 lines · Anand Suveer Jain
fs/btrfs/super.c +0
-0@@ -1836,8 +1836,12 @@ static int btrfs_statfs(struct dentry *dentry, struct kstatfs *buf) f_fsid.val[0] ^= btrfs_root_id(BTRFS_I(d_inode(dentry))->root) >> 32; f_fsid.val[1 ] ^=btrfs_root_id (BTRFS_I (d_inode (dentry))->root);fs/btrfs/super.c static int btrfs_statfs(struct dentry *dentry, · line 1847
Quoted 10 lines
fs/btrfs/super.c +6
-2-/* Hash dev_t to avoid f_fsid collision with cloned filesystems. */ -if (fs_info->fs_devices->total_devices ==1 ) { +/* +* Hash dev_t to avoid f_fsid collisions with cloned filesystems. +* Only do this when a clone is present so the original filesystem +* (mounted first) maintains backward-compatible f_fsid behavior. +*/ +if (fs_info->fs_devices->temp_fsid) { __kernel_fsid_t dev_fsid =
Quoted 4 lines
This should fix the most common case where people don't have any cloned filesystems at all, so I guess this is good as a fix. Please send it so I can add it to this -rc pull request. We can try to catch next week's release of stable trees.
The fix is already on the ML.
Quoted 3 lines
Related to the cloned filesystems, it can get complicated if the original filesystem gets unmounted and mounted again, now it would have the
temp_fsidset, right?
No, it won't. Once unmounted, there is no longer an active fs_devices using that original UUID in the system, so the next mount will claim the original UUID without needing temp_fsid.
Quoted 3 lines
I don't see the
temp_fsiddocumented (btrfs-progs) other than in the changelogs and briefly in the sysfs file. This should be more visible as a separate feature and with the known use cases.
Agreed. Do you think btrfs(5) is a good place to document temp_fsid?
Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t
Quoted 5 lines · Anand Suveer Jain
Quoted 3 lines
I don't see the
temp_fsiddocumented (btrfs-progs) other than in the changelogs and briefly in the sysfs file. This should be more visible as a separate feature and with the known use cases.Agreed. Do you think btrfs(5) is a good place to document
temp_fsid?
Yes, please add a section and also explain the other filesystem ids and how they're related. We can add references from other places using it (sysfs, mount and others).
Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t
Quoted 10 lines · David Sterba
Quoted 5 lines · Anand Suveer Jain
Quoted 3 lines
I don't see the
temp_fsiddocumented (btrfs-progs) other than in the changelogs and briefly in the sysfs file. This should be more visible as a separate feature and with the known use cases.Agreed. Do you think btrfs(5) is a good place to document
temp_fsid?Yes, please add a section and also explain the other filesystem ids and how they're related. We can add references from other places using it (sysfs, mount and others).
Just to close the loop: the man page update was sent last week.
https://lore.kernel.org/linux-btrfs/20260918084612.ZxGVtNO9DAJfevT0EwV5BlMy-4qgIyRKK6TAZ5oNLtU@z/
David (Sterba), once commit c2a74ed0494c is reverted, based on its final take, I will update the fstests test case on the mailing list accordingly.
PATCH 2/3 btrfs: use on-disk uuid for s_uuid in temp_fsid mounts
In reply to Anand JainWhen 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.
--- fs/btrfs/disk-io.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/btrfs/disk-io.c +2 -1
@@ -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);
Signature · 1 line
2.43.0
RFC PATCH 3/3 ext4: derive f_fsid from block device to avoid collisions
In reply to Anand Jainstatfs() currently reports f_fsid derived from the on-disk UUID. Cloned block devices share the same UUID, so distinct ext4 instances can return identical f_fsid values. This leads to collisions in fanotify.
Encode sb->s_dev into f_fsid instead of using the superblock UUID. This provides a per-device identifier and avoids conflicts when filesystem is cloned, matching the behavior with xfs.
Marking as RFC: it is unclear whether any usecase requires the f_fsid of a cloned filesystem to be consistent with that of the source filesystem.
--- fs/ext4/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext4/super.c +1 -1
@@ -6941,7 +6941,7 @@ static int ext4_statfs(struct dentry *dentry, struct kstatfs *buf) buf->f_files =le32_to_cpu (es->s_inodes_count); buf->f_ffree =percpu_counter_sum_positive (&sbi->s_freeinodes_counter); buf->f_namelen =EXT4_NAME_LEN ; - buf->f_fsid =uuid_to_fsid (es->s_uuid); + buf->f_fsid =u64_to_fsid (huge_encode_dev (sb->s_dev));#ifdef CONFIG_QUOTA if (ext4_test_inode_flag(dentry->d_inode, EXT4_INODE_PROJINHERIT) &&
Signature · 1 line
2.43.0
Quoted 4 lines · Anand Jain
This series resolves the tradeoff by aligning btrfs and ext4 behaviour with XFS:
f_fsidincorporates device identity (devt) to remain unique across clones, whiles_uuidis 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?
Quoted 5 lines
Patches
-------
Patch 1/3: btrfs: fixf_fsidto include rootid and devt
Patch 2/3: btrfs: fixs_uuidto be stable across mounts for cloned filesystems Patch 3/3: ext4: fixf_fsidto use devt instead ofs_uuid
I don't really see that patch 3 in my inbox on linux-btrfs.
Quoted 9 lines · Christoph Hellwig
Quoted 4 lines · Anand Jain
This series resolves the tradeoff by aligning btrfs and ext4 behaviour with XFS:
f_fsidincorporates device identity (devt) to remain unique across clones, whiles_uuidis preserved consistently matching the on-disk uuid.While I like fixing this up, switching the
f_fsidconstruction 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).
Quoted 7 lines
Quoted 5 lines
Patches
-------
Patch 1/3: btrfs: fixf_fsidto include rootid and devt
Patch 2/3: btrfs: fixs_uuidto be stable across mounts for cloned filesystems Patch 3/3: ext4: fixf_fsidto use devt instead ofs_uuidI 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:
Thanks, Anand
Quoted 6 lines · Anand Jain
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_fsidshould 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?
Theodore Tso
maintainerQuoted 8 lines · Anand Jain
| 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?
Quoted 11 lines
Problem
-------
Btrfs currently never duplicatess_uuidorf_fsidfor 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_fsidit sees keeps changing. This does not scale. Whereas on the otherhand if you have sames_uuidon 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.
Quoted 5 lines
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_FIDevents will fail to resolve to the correct mountpoint whenf_fsidvalues 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