Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles
From: André Almeida
Date: Thu Jan 15 2026 - 10:43:03 EST
Em 15/01/2026 04:23, Christoph Hellwig escreveu:
[...]
I still wonder what the use case is here. Looking at André's original
mail it states:
"However, btrfs mounts may have volatiles UUIDs. When mounting the exact same
disk image with btrfs, a random UUID is assigned for the following disks each
time they are mounted, stored at temp_fsid and used across the kernel as the
disk UUID. `btrfs filesystem show` presents that. Calling statfs() however
shows the original (and duplicated) UUID for all disks."
and this doesn't even talk about multiple mounts, but looking at
device_list_add it seems to only set the temp_fsid flag when set
same_fsid_diff_dev is set by find_fsid_by_device, which isn't documented
well, but does indeed seem to be done transparently when two file systems
with the same fsid are mounted.
So André, can you confirm this what you're worried about? And btrfs
developers, I think the main problem is indeed that btrfs simply allows
mounting the same fsid twice. Which is really fatal for anything using
the fsid/uuid, such NFS exports, mount by fs uuid or any sb->s_uuid user.
Yes, I'm would like to be able to mount two cloned btrfs images and to use overlayfs with them. This is useful for SteamOS A/B partition scheme.
If so, I think it's time to revert the behavior before it's too late.
Currently the main usage of such duplicated fsids is for Steam deck to
maintain A/B partitions, I think they can accept a new compat_ro flag for
that.
What's an A/B partition? And how are these safely used at the same time?
The Steam Deck have two main partitions to install SteamOS updates atomically. When you want to update the device, assuming that you are using partition A, the updater will write the new image in partition B, and vice versa. Then after the reboot, the system will mount the new image on B.
Android used to support A/B scheme as well: https://source.android.com/docs/core/ota/ab