Message-ID: <33c1ccbd-abbe-4278-8ab1-d7d645c8b6e8@igalia.com>
Date: Fri, 16 Jan 2026 10:27:52 -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, vivek@...labora.com,
 Ludovico de Nittis <ludovico.denittis@...labora.com>
Subject: Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles

[+CC SteamOS developers]

Em 16/01/2026 06:55, Amir Goldstein escreveu:
> On Thu, Jan 15, 2026 at 7:55 PM André Almeida <andrealmeid@...lia.com> wrote:
>>
>> 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.
> 
> Please describe the exact overlayfs setup and specifically,
> is it multi lower or single lower layer setup?
> What reason do you need the overlayfs index for?
> Can you mount with index=off which should relax the hard
> requirement for match with the original lower layer uuid.
> 

The setup has a single lower layer. This is how the mount command looks 
like:

mount -t overlay -o 
"lowerdir=${DEV_DIR}/etc,upperdir=${DEV_DIR}/var/lib/overlays/etc/upper,workdir=${DEV_DIR}/var/lib/overlays/etc/work" 
none "${DEV_DIR}/etc"

They would rather not disable index, to avoid mounting the wrong layers 
and to avoid corner cases with hardlinks.

Powered by blists - more mailing lists