From: Anand Jain <asj@kernel.org>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t
Date: Thu, 26 Feb 2026 22:27:19 +0800 [thread overview]
Message-ID: <fdea3f42827f512fcaa82f4dabe475e191d7ff2f.1772095546.git.asj@kernel.org> (raw)
In-Reply-To: <cover.1772095546.git.asj@kernel.org>
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
next prev parent reply other threads:[~2026-02-26 14:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 14:23 [PATCH 0/3] fix s_uuid and f_fsid consistency for cloned filesystems Anand Jain
2026-02-26 14:27 ` Anand Jain [this message]
2026-02-26 14:27 ` [PATCH 2/3] btrfs: use on-disk uuid for s_uuid in temp_fsid mounts Anand Jain
2026-03-04 13:28 ` [PATCH 0/3] fix s_uuid and f_fsid consistency for cloned filesystems Christoph Hellwig
2026-03-05 9:32 ` Anand Jain
2026-03-05 14:21 ` Christoph Hellwig
2026-03-22 20:31 ` Theodore Tso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fdea3f42827f512fcaa82f4dabe475e191d7ff2f.1772095546.git.asj@kernel.org \
--to=asj@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox