Re: [PATCH 1/3] btrfs: derive f_fsid from on-disk fsuuid and dev_t

[Anand Suveer Jain <asj@kernel.org>]

On 14/9/26 21:14, David Sterba wrote:
> On Sat, Sep 12, 2026 at 06:19:21PM +0800, Anand Suveer Jain wrote:
>> --- 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 =
> 


> This should fix the most common case where people don't have any cloned
> filesystems at all, so I guess this is good as a fix. Please send it so
> I can add it to this -rc pull request. We can try to catch next week's
> release of stable trees.


The fix is already on the ML.

https://lore.kernel.org/linux-btrfs/16069a6fc651168bfcd2394d6e57ce63a50231ed.1789235482.git.asj@kernel.org/

> Related to the cloned filesystems, it can get complicated if the
> original filesystem gets unmounted and mounted again, now it would have
> the temp_fsid set, right?

No, it won't. Once unmounted, there is no longer an active fs_devices
using that original UUID in the system, so the next mount will claim the
original UUID without needing temp_fsid.

> I don't see the temp_fsid documented (btrfs-progs) other than in the
> changelogs and briefly in the sysfs file. This should be more visible as
> a separate feature and with the known use cases.

Agreed. Do you think btrfs(5) is a good place to document temp_fsid?