[PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[Anand Jain]

Commit c2a74ed0494c ("btrfs: derive f_fsid from on-disk fsid and dev_t")
mixed dev_t into f_fsid for all single-device setups to avoid f_fsid
collisions with cloned filesystems.

However, doing this unconditionally breaks backward compatibility.
statfs(2) f_fsid changes after a kernel upgrade, and also can shift
across reboots or dev re-attaches as dev_t values change.

Fix this by only mixing dev_t when temp_fsid is active.
This means for non-temp_fsid setups or the original mount, we use the
old method of deriving fsid based on the UUID.

So in the case of a cloned Btrfs filesystem, we won't be able to
maintain the same fsid across mount recycle if the mount order
changes.

Fixes: c2a74ed0494c ("btrfs: derive f_fsid from on-disk fsid and dev_t")
Reported-by: Dave Hansen <dave.hansen@intel.com>
Closes: https://lore.kernel.org/linux-btrfs/be0c08f5-2f31-40f5-8a3b-f2f58b3e00ff@intel.com
Signed-off-by: Anand Jain <asj@kernel.org>
---
 Dave (Hansen), I wonder if you could verify whether this fixes the issue
 on your end. I have run some limited test cases from fstests as of now,
 and they passed.

 fs/btrfs/super.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 464129b1b0d4..ddb620ac241b 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -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);
 
-	/* 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));
 
-- 
2.43.0

Re: [PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[Dave Hansen]

On 9/12/26 11:06, Anand Jain wrote:
>  Dave (Hansen), I wonder if you could verify whether this fixes the issue
>  on your end. I have run some limited test cases from fstests as of now,
>  and they passed.

I actually didn't hit it personally, but I'll pass it along to folks
that are hitting it.

BTW, this is hitting folks running 7.2, iirc. Could whoever commits it
and sends it up to Linus tag it for stable, please?

Re: [PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[Anand Suveer Jain]

On 13/9/26 05:58, Dave Hansen wrote:
> On 9/12/26 11:06, Anand Jain wrote:
>>  Dave (Hansen), I wonder if you could verify whether this fixes the issue
>>  on your end. I have run some limited test cases from fstests as of now,
>>  and they passed.
> 
> I actually didn't hit it personally, but I'll pass it along to folks
> that are hitting it.
> 
> BTW, this is hitting folks running 7.2, iirc. Could whoever commits it
> and sends it up to Linus tag it for stable, please?


 The patch includes the Fixes: tag, so once it merges into mainline,
 it should be queued for the stable releases shortly after.

Re: [PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[Dave Hansen]

On 9/12/26 18:05, Anand Suveer Jain wrote:
...
>> BTW, this is hitting folks running 7.2, iirc. Could whoever commits it
>> and sends it up to Linus tag it for stable, please?
> 
>  The patch includes the Fixes: tag, so once it merges into mainline,
>  it should be queued for the stable releases shortly after.

Did something change there? Or is there something special about fs/ or
btrfs here? I know Sasha's scripts tend to go out and magically find
things. But I thought the best (and only documented) process was still
to add explicit stable tags.

Documentation/process/stable-kernel-rules.rst doesn't say anywhere that
I can see that a Fixes tag along is sufficient.

If you're right, then awesome! I can forget about Cc:stable@ and just
focus on Fixes: tags alone.

Re: [PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[Anand Suveer Jain]

On 13/9/26 09:13, Dave Hansen wrote:
> On 9/12/26 18:05, Anand Suveer Jain wrote:
> ...
>>> BTW, this is hitting folks running 7.2, iirc. Could whoever commits it
>>> and sends it up to Linus tag it for stable, please?
>>
>>  The patch includes the Fixes: tag, so once it merges into mainline,
>>  it should be queued for the stable releases shortly after.
> 
> Did something change there? Or is there something special about fs/ or
> btrfs here? I know Sasha's scripts tend to go out and magically find
> things. But I thought the best (and only documented) process was still
> to add explicit stable tags.
> 
> Documentation/process/stable-kernel-rules.rst doesn't say anywhere that
> I can see that a Fixes tag along is sufficient.
> 
> If you're right, then awesome! I can forget about Cc:stable@ and just
> focus on Fixes: tags alone.

Yeah, you're right. Adding Cc: stable@ is still the right way to do it.

f_fsid has been pretty tricky to handle lately, so I just wanted to let
the patch sit on the btrfs list for a couple of days first to get some
review.

I'll make sure it gets into stable.

Re: [PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[Anand Suveer Jain]

This issue and its current fix (below) have been on my mind, as I wasn't
fully satisfied with the approach even though it works.

Now, I think I have a better idea.

The core issue isn't that the new f_fsid derivation is wrong (recap:
f_fsid derivation changed from f(UUID) to f(UUID + dev_t)). Rather, the
problem is that f_fsid changes unexpectedly after an upgrade.

So we need to address the upgrade behavior, not how f_fsid itself is
derived.

My new proposed solution:

 . Put the new f_fsid derivation behind a compile-time config flag (an
incompat/opt-in flag).
 . For stable kernels, this flag will keep the new f_fsid derivation
disabled by default.

The only drawback I see with this approach is that it adds yet another
incompat flag, making the incompat feature list even longer.

Please let me know what you think. I can send out v2 with these changes
on Tuesday.

Thanks, Anand


On 13/9/26 02:06, Anand Jain wrote:
> Commit c2a74ed0494c ("btrfs: derive f_fsid from on-disk fsid and dev_t")
> mixed dev_t into f_fsid for all single-device setups to avoid f_fsid
> collisions with cloned filesystems.
> 
> However, doing this unconditionally breaks backward compatibility.
> statfs(2) f_fsid changes after a kernel upgrade, and also can shift
> across reboots or dev re-attaches as dev_t values change.
> 
> Fix this by only mixing dev_t when temp_fsid is active.
> This means for non-temp_fsid setups or the original mount, we use the
> old method of deriving fsid based on the UUID.
> 
> So in the case of a cloned Btrfs filesystem, we won't be able to
> maintain the same fsid across mount recycle if the mount order
> changes.
> 
> Fixes: c2a74ed0494c ("btrfs: derive f_fsid from on-disk fsid and dev_t")
> Reported-by: Dave Hansen <dave.hansen@intel.com>
> Closes: https://lore.kernel.org/linux-btrfs/be0c08f5-2f31-40f5-8a3b-f2f58b3e00ff@intel.com
> Signed-off-by: Anand Jain <asj@kernel.org>
> ---
>  Dave (Hansen), I wonder if you could verify whether this fixes the issue
>  on your end. I have run some limited test cases from fstests as of now,
>  and they passed.
> 
>  fs/btrfs/super.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 464129b1b0d4..ddb620ac241b 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -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);
>  
> -	/* 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] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[David Woodhouse]

On 14 September 2026 04:42:51 BST, Anand Suveer Jain <asj@kernel.org> wrote:
>
>
>This issue and its current fix (below) have been on my mind, as I wasn't
>fully satisfied with the approach even though it works.
>
>Now, I think I have a better idea.
>
>The core issue isn't that the new f_fsid derivation is wrong (recap:
>f_fsid derivation changed from f(UUID) to f(UUID + dev_t)). Rather, the
>problem is that f_fsid changes unexpectedly after an upgrade.
>
>So we need to address the upgrade behavior, not how f_fsid itself is
>derived.
>
>My new proposed solution:
>
> . Put the new f_fsid derivation behind a compile-time config flag (an
>incompat/opt-in flag).
> . For stable kernels, this flag will keep the new f_fsid derivation
>disabled by default.

No. That still gives you a broken fsid on upgrading to the next major kernel, doesn't it? Maybe a new flag on the file system itself to indicate that its stable FSID is computed using the new scheme.

Re: [PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[Anand Suveer Jain]

>> . For stable kernels, this flag will keep the new f_fsid derivation
>> disabled by default.


> No. That still gives you a broken fsid on upgrading to the next major kernel, doesn't it?

Upgrading to a _major_ kernel would require an extra step to re-encrypt
with the new FSID _for some configs_.
A one-time operational overhead.

> Maybe a new flag on the file system itself to indicate that its
> stable FSID is computed using the new scheme.

A mkfs-time or runtime switch, something like:
  /sys/fs/btrfs/<UUID>/enable_collision_free_fsid
(just as an example) is an option.
However, persisting an on-disk flag for this feels like using a cannon
to kill a mosquito.

Feedback/suggestions are welcome.

Re: [PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

On Mon, 2026-09-14 at 16:28 +0800, Anand Suveer Jain wrote:
> 
> 
> > > . For stable kernels, this flag will keep the new f_fsid derivation
> > > disabled by default.
> 
> 
> > No. That still gives you a broken fsid on upgrading to the next major kernel, doesn't it?
> 
> Upgrading to a _major_ kernel would require an extra step to re-encrypt
> with the new FSID _for some configs_.
> A one-time operational overhead.

I'm not keen on that. The documentation is fairly poor, but historical
behaviour and expectation is that the FSID is supposed to be *stable*.
You're not supposed to randomly change it from one kernel to the next.
Won't this also trigger some incremental backup schemes to re-archive
every file as it seems the {fsid, ino} has changed?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]

Re: [PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[Anand Suveer Jain]

> The documentation is fairly poor, but historical
> behaviour and expectation is that the FSID is supposed to be *stable*.

It's definitely messy.

Statfs f_fsid was never strictly guaranteed to be persistent across
reboots when derived from dev_t, filesystems like XFS and F2FS share the
same design.

Historically, the documentation around f_fsid has been ambiguous,
leading to different expectations across filesystems.

Breaking tools that rely on a stable {fsid, ino} is a real problem.

The idea with this patch is to restore the original behavior as the
default, and an option to mix in dev_t when needed to avoid collisions.

Re: [PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[David Sterba]

On Mon, Sep 14, 2026 at 12:47:53PM +0200, David Woodhouse wrote:
> On Mon, 2026-09-14 at 16:28 +0800, Anand Suveer Jain wrote:
> > 
> > 
> > > > . For stable kernels, this flag will keep the new f_fsid derivation
> > > > disabled by default.
> > 
> > 
> > > No. That still gives you a broken fsid on upgrading to the next major kernel, doesn't it?
> > 
> > Upgrading to a _major_ kernel would require an extra step to re-encrypt
> > with the new FSID _for some configs_.
> > A one-time operational overhead.
> 
> I'm not keen on that. The documentation is fairly poor, but historical
> behaviour and expectation is that the FSID is supposed to be *stable*.
> You're not supposed to randomly change it from one kernel to the next.

That's what I consider sane and would like to preserve. We allow users
to change the UUID by tools, but this means the user is aware of that
and initiating such action.

> Won't this also trigger some incremental backup schemes to re-archive
> every file as it seems the {fsid, ino} has changed?

This is a good point, I don't know if backup tools do that but it's
quite natual thing to do.

Re: [PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[David Sterba]

On Mon, Sep 14, 2026 at 04:28:25PM +0800, Anand Suveer Jain wrote:
> 
> 
> >> . For stable kernels, this flag will keep the new f_fsid derivation
> >> disabled by default.
> 
> 
> > No. That still gives you a broken fsid on upgrading to the next major kernel, doesn't it?
> 
> Upgrading to a _major_ kernel would require an extra step to re-encrypt
> with the new FSID _for some configs_.
> A one-time operational overhead.

It's fairly common to boot different kernel versions on the same system,
so the upgrade is perhaps installing it but the assumptions about what's
working do not change. I have mixed results upgrading kernel and Nvidia
drivers and imagining that I'd have to re-encrypt anything just between
reboots sounds like usability antipattern.

> > Maybe a new flag on the file system itself to indicate that its
> > stable FSID is computed using the new scheme.
> 
> A mkfs-time or runtime switch, something like:
>   /sys/fs/btrfs/<UUID>/enable_collision_free_fsid
> (just as an example) is an option.

Even as a conceptual idea this does not improve things, users do not
care about this level of detail. We already have enough problems
defining correct behaviour with fsid, metadata uuid in combination with
the temp_fsid and seeding.

Re: [PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[David Sterba]

On Mon, Sep 14, 2026 at 11:42:51AM +0800, Anand Suveer Jain wrote:
> 
> 
> This issue and its current fix (below) have been on my mind, as I wasn't
> fully satisfied with the approach even though it works.
> 
> Now, I think I have a better idea.
> 
> The core issue isn't that the new f_fsid derivation is wrong (recap:
> f_fsid derivation changed from f(UUID) to f(UUID + dev_t)). Rather, the
> problem is that f_fsid changes unexpectedly after an upgrade.
> 
> So we need to address the upgrade behavior, not how f_fsid itself is
> derived.
> 
> My new proposed solution:
> 
>  . Put the new f_fsid derivation behind a compile-time config flag (an
> incompat/opt-in flag).

A compile-time change should be only something really significant for
the whole filesystem. Configs rarely change and except
developers/embedded/custom builds it's hard to change, speaking about
distros.

Re: [PATCH] btrfs: derive f_fsid with dev_t only when temp_fsid is active

[Anand Suveer Jain]

On 15/9/26 00:46, David Sterba wrote:
> On Mon, Sep 14, 2026 at 11:42:51AM +0800, Anand Suveer Jain wrote:
>>
>>
>> This issue and its current fix (below) have been on my mind, as I wasn't
>> fully satisfied with the approach even though it works.
>>
>> Now, I think I have a better idea.
>>
>> The core issue isn't that the new f_fsid derivation is wrong (recap:
>> f_fsid derivation changed from f(UUID) to f(UUID + dev_t)). Rather, the
>> problem is that f_fsid changes unexpectedly after an upgrade.
>>
>> So we need to address the upgrade behavior, not how f_fsid itself is
>> derived.
>>
>> My new proposed solution:
>>
>>  . Put the new f_fsid derivation behind a compile-time config flag (an
>> incompat/opt-in flag).
> 
> A compile-time change should be only something really significant for
> the whole filesystem. Configs rarely change and except
> developers/embedded/custom builds it's hard to change, speaking about
> distros.

I'm responding to other emails collectively here:

In that case, I think it's better to revert the commit c2a74ed0494c
("btrfs: derive f_fsid from on-disk fsid and dev_t"). That gives us
consistent statfs f_fsid behavior in the new kernel and for
temp_fsid-mounted filesystems, f_fsid will be the random value generated
at mount time, and it becomes the responsibility of the use case to
change the UUID (and move away from relying on temp_fsid) if persistent
identification is required. btrfs(5) is updated [1] in the ML.

 [1]
https://lore.kernel.org/linux-btrfs/20260918084612.ZxGVtNO9DAJfevT0EwV5BlMy-4qgIyRKK6TAZ5oNLtU@z/