From: Anand Jain <asj@kernel.org>
To: linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: [PATCH 0/3] fix s_uuid and f_fsid consistency for cloned filesystems
Date: Thu, 26 Feb 2026 22:23:32 +0800 [thread overview]
Message-ID: <cover.1772095546.git.asj@kernel.org> (raw)
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
next reply other threads:[~2026-02-26 14:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 14:23 Anand Jain [this message]
2026-02-26 14:27 ` [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t Anand Jain
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=cover.1772095546.git.asj@kernel.org \
--to=asj@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@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