Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Anand Jain <asj@kernel.org>
To: linux-btrfs@vger.kernel.org, dsterba@suse.cz
Cc: Your Name <you@example.com>
Subject: [PATCH] btrfs-progs: docs: document the temp_fsid feature in btrfs(5)
Date: Fri, 18 Sep 2026 16:42:43 +0800	[thread overview]
Message-ID: <b49b0307f3622febb1ae5c87db10b5de032ec967.1789720953.git.asj@kernel.org> (raw)

From: Your Name <you@example.com>

The temp_fsid feature (kernel 6.7) is missing from the FILESYSTEM
FEATURES list in btrfs(5). It's exposed in sysfs
(/sys/fs/btrfs/features/temp_fsid and /sys/fs/btrfs/<UUID>/temp_fsid)
like any other feature, but has no corresponding entry in the manual
page.

Add an entry describing what it does, when it applies (single-device
filesystems only) and its exclusivity with metadata_uuid, following
the existing entry format and alphabetical ordering.

Signed-off-by: Anand Jain <asj@kernel.org>
---
 Documentation/btrfs-man5.rst | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Documentation/btrfs-man5.rst b/Documentation/btrfs-man5.rst
index ce4021ab84b5..2635f06a1394 100644
--- a/Documentation/btrfs-man5.rst
+++ b/Documentation/btrfs-man5.rst
@@ -199,6 +199,22 @@ supported_rescue_options
         list of values for the mount option *rescue* that are supported by the running
         kernel, see :doc:`btrfs-man5`
 
+temp_fsid
+	(since: 6.7)
+
+	indicates the filesystem is mounted using a randomly generated, in-memory only
+	substitute for the on-disk filesystem UUID, needed because another filesystem
+	exposing the same UUID (e.g. a block-level clone) is already mounted. The
+	on-disk UUID, as reported by :command:`blkid`, is unchanged; the statfs
+	filesystem ID *f_fsid* returned by :manref:`statfs(2)` for this mount reflects
+	the substitute, and is regenerated on every such mount.
+
+	Supported only for single-device filesystems, mutually exclusive with
+	*metadata_uuid*, and disables :command:`device add` for the mount. To make a
+	clone permanently independent instead of relying on temp_fsid on every mount,
+	change its on-disk UUID with :doc:`btrfstune` (*-u* or *-U*) while unmounted.
+	See also section :ref:`SYSFS INTERFACE<man-btrfs5-sysfs-interface>`.
+
 vefity
         (since: 5.15, CONFIG_FS_VERITY)
 
-- 
2.43.0


WARNING: multiple messages have this Message-ID (diff)
From: Anand Jain <asj@kernel.org>
To: linux-btrfs@vger.kernel.org, dsterba@suse.cz
Subject: [PATCH] btrfs-progs: docs: document the temp_fsid feature in btrfs(5)
Date: Fri, 18 Sep 2026 16:46:12 +0800	[thread overview]
Message-ID: <b49b0307f3622febb1ae5c87db10b5de032ec967.1789720953.git.asj@kernel.org> (raw)
Message-ID: <20260918084612.ZxGVtNO9DAJfevT0EwV5BlMy-4qgIyRKK6TAZ5oNLtU@z> (raw)

The temp_fsid feature (kernel 6.7) is missing from the FILESYSTEM
FEATURES list in btrfs(5). It's exposed in sysfs
(/sys/fs/btrfs/features/temp_fsid and /sys/fs/btrfs/<UUID>/temp_fsid)
like any other feature, but has no corresponding entry in the manual
page.

Add an entry describing what it does, when it applies (single-device
filesystems only) and its exclusivity with metadata_uuid, following
the existing entry format and alphabetical ordering.

Signed-off-by: Anand Jain <asj@kernel.org>
---
 Documentation/btrfs-man5.rst | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Documentation/btrfs-man5.rst b/Documentation/btrfs-man5.rst
index ce4021ab84b5..2635f06a1394 100644
--- a/Documentation/btrfs-man5.rst
+++ b/Documentation/btrfs-man5.rst
@@ -199,6 +199,22 @@ supported_rescue_options
         list of values for the mount option *rescue* that are supported by the running
         kernel, see :doc:`btrfs-man5`
 
+temp_fsid
+	(since: 6.7)
+
+	indicates the filesystem is mounted using a randomly generated, in-memory only
+	substitute for the on-disk filesystem UUID, needed because another filesystem
+	exposing the same UUID (e.g. a block-level clone) is already mounted. The
+	on-disk UUID, as reported by :command:`blkid`, is unchanged; the statfs
+	filesystem ID *f_fsid* returned by :manref:`statfs(2)` for this mount reflects
+	the substitute, and is regenerated on every such mount.
+
+	Supported only for single-device filesystems, mutually exclusive with
+	*metadata_uuid*, and disables :command:`device add` for the mount. To make a
+	clone permanently independent instead of relying on temp_fsid on every mount,
+	change its on-disk UUID with :doc:`btrfstune` (*-u* or *-U*) while unmounted.
+	See also section :ref:`SYSFS INTERFACE<man-btrfs5-sysfs-interface>`.
+
 vefity
         (since: 5.15, CONFIG_FS_VERITY)
 
-- 
2.43.0


             reply	other threads:[~2026-09-18  8:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18  8:42 Anand Jain [this message]
2026-09-18  8:46 ` [PATCH] btrfs-progs: docs: document the temp_fsid feature in btrfs(5) Anand Jain
2026-09-18  8:47 ` Anand Suveer Jain

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=b49b0307f3622febb1ae5c87db10b5de032ec967.1789720953.git.asj@kernel.org \
    --to=asj@kernel.org \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=you@example.com \
    /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