Message-ID: <0241e2c4-bf11-4372-9eda-cccaba4a6d7d@igalia.com>
Date: Thu, 15 Jan 2026 15:55:15 -0300
From: André Almeida <andrealmeid@...lia.com>
To: Amir Goldstein <amir73il@...il.com>
Cc: Christoph Hellwig <hch@....de>, Chuck Lever <chuck.lever@...cle.com>,
 Jeff Layton <jlayton@...nel.org>, NeilBrown <neil@...wn.name>,
 Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo <Dai.Ngo@...cle.com>,
 Tom Talpey <tom@...pey.com>, Carlos Maiolino <cem@...nel.org>,
 Chris Mason <clm@...com>, David Sterba <dsterba@...e.com>,
 Miklos Szeredi <miklos@...redi.hu>, Christian Brauner <brauner@...nel.org>,
 Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
 linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 Qu Wenruo <wqu@...e.com>, linux-btrfs@...r.kernel.org,
 linux-unionfs@...r.kernel.org, kernel-dev@...lia.com
Subject: Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

Em 15/01/2026 13:07, Amir Goldstein escreveu:
> On Thu, Jan 15, 2026 at 4:42 PM André Almeida <andrealmeid@...lia.com> 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.

Powered by blists - more mailing lists