Message-ID: <CAOQ4uxgCM=q29Vs+35y-2K9k7GP2A2NfPkuqCrUiMUHW+KhbWw@mail.gmail.com>
Date: Fri, 16 Jan 2026 18:06:22 +0100
From: Amir Goldstein <amir73il@...il.com>
To: André Almeida <andrealmeid@...lia.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

On Fri, Jan 16, 2026 at 2:28 PM André Almeida <andrealmeid@...lia.com> 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@...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.

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@...tuozzo.com>
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.

Thanks,
Amir.

Powered by blists - more mailing lists