Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[André Almeida]

Em 15/01/2026 13:07, Amir Goldstein escreveu:
> On Thu, Jan 15, 2026 at 4:42 PM André Almeida <andrealmeid@xxxxxxxxxx> wrote:
> > 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.
>
> And what do you expect to happen wrt overlayfs when switching from
> image A to B?
>
> What are the origin file handles recorded in overlayfs index from image A
> lower worth when the lower image is B?
>
> Is there any guarantee that file handles are relevant and point to the
> same objects?
>
> The whole point of the overlayfs index feature is that overlayfs inodes
> can have a unique id across copy-up.
>
> Please explain in more details exactly which overlayfs setup you are
> trying to do with index feature.

The problem happens _before_ switching from A to B, it happens when 
trying to install the same image from A on B.

During the image installation process, while running in A, the B image 
will be mounted more than once for some setup steps, and overlayfs is 
used for this. Because A have the same UUID, each time B is remouted 
will get a new UUID and then the installation scripts fails mounting the 
image.