Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles
From: André Almeida
Date: Mon Jan 19 2026 - 11:57:05 EST
Em 16/01/2026 14:06, Amir Goldstein escreveu:
On Fri, Jan 16, 2026 at 2:28 PM André Almeida <andrealmeid@xxxxxxxxxx> wrote:
[+CC SteamOS developers]
Em 16/01/2026 06:55, Amir Goldstein escreveu:
On Thu, Jan 15, 2026 at 7:55 PM André Almeida <andrealmeid@xxxxxxxxxx> wrote:
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.
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.
IIUC you have all the layers on the same fs ($DEV_DIR)?
See mount option uuid=off, created for this exact use case:
Documentation/filesystems/overlayfs.rst:
Note: the mount option uuid=off can be used to replace UUID of the underlying
filesystem in file handles with null, and effectively disable UUID checks. This
can be useful in case the underlying disk is copied and the UUID of this copy
is changed. This is only applicable if all lower/upper/work directories are on
the same filesystem, otherwise it will fallback to normal behaviour.
commit 5830fb6b54f7167cc7c9d43612eb01c24312c7ca
Author: Pavel Tikhomirov <ptikhomirov@xxxxxxxxxxxxx>
Date: Tue Oct 13 17:59:54 2020 +0300
ovl: introduce new "uuid=off" option for inodes index feature
This replaces uuid with null in overlayfs file handles and thus relaxes
uuid checks for overlay index feature. It is only possible in case there is
only one filesystem for all the work/upper/lower directories and bare file
handles from this backing filesystem are unique. In other case when we have
multiple filesystems lets just fallback to "uuid=on" which is and
equivalent of how it worked before with all uuid checks.
This is needed when overlayfs is/was mounted in a container with index
enabled ...
If you just change the uuid of the backing filesystem, overlay is not
mounting any more. In Virtuozzo we copy container disks (ploops) when
create the copy of container and we require fs uuid to be unique for a new
container.
TBH, I am trying to remember why we require upper/work to be on the
same fs as lower for uuid=off,index=on and I can't remember.
If this is important I can look into it.
Actually they are not in the same fs, upper and lower are coming from different fs', so when trying to mount I get the fallback to `uuid=null`. A quick hack circumventing this check makes the mount work.
If you think this is the best way to solve this issue (rather than following the VFS helper path for instance), please let me know how can I safely lift this restriction, like maybe adding a new flag for this?
Thanks,
Amir.