public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
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


             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