Message-ID: <CAOQ4uxgzK7qYDFWYT62jH_zq8JkLGussD5ro4cKDqSNQqBiVUA@mail.gmail.com>
Date: Fri, 6 Feb 2026 14:12:21 +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 Thu, Feb 5, 2026 at 9:34 PM André Almeida <andrealmeid@...lia.com> wrote:
>
> Em 28/01/2026 08:49, Amir Goldstein escreveu:
> > On Sat, Jan 24, 2026 at 11:45 AM Amir Goldstein <amir73il@...il.com> wrote:
> >>
> >> On Fri, Jan 23, 2026 at 9:08 PM André Almeida <andrealmeid@...lia.com> wrote:
> >>>
> >>> Em 23/01/2026 10:24, André Almeida escreveu:
> >>>>
> >>>> Em 22/01/2026 17:07, Amir Goldstein escreveu:
> >>>>> On Tue, Jan 20, 2026 at 4:12 PM Amir Goldstein <amir73il@...il.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> On Mon, Jan 19, 2026 at 5:56 PM André Almeida
> >>>>>> <andrealmeid@...lia.com> wrote:
> >>>>>>>
> >>>>> ...
> >>>>>>> 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),
> >>>>>>
> >>>>>> That's up to you if you want to solve the "all lower layers on same fs"
> >>>>>> or want to also allow lower layers on different fs.
> >>>>>> The former could be solved by relaxing the ovl rules.
> >>>>>>
> >>>>>>> please let me know how can
> >>>>>>> I safely lift this restriction, like maybe adding a new flag for this?
> >>>>>>
> >>>>>> I think the attached patch should work for you and should not
> >>>>>> break anything.
> >>>>>>
> >>>>>> It's only sanity tested and will need to write tests to verify it.
> >>>>>>
> >>>>>
> >>>>> Andre,
> >>>>>
> >>>>> I tested the patch and it looks good on my side.
> >>>>> If you want me to queue this patch for 7.0,
> >>>>> please let me know if it addresses your use case.
> >>>>>
> >>>>
> >>>> Hi Amir,
> >>>>
> >>>> I'm still testing it to make sure it works my case, I will return to you
> >>>> ASAP. Thanks for the help!
> >>>>
> >>>
> >>> So, your patch wasn't initially working in my setup here, and after some
> >>> debugging it turns out that on ovl_verify_fh() *fh would have a NULL
> >>> UUID, but *ofh would have a valid UUID, so the compare would then fail.
> >>>
> >>> Adding this line at ovl_get_fh() fixed the issue for me and made the
> >>> patch work as I was expecting:
> >>>
> >>> +       if (!ovl_origin_uuid(ofs))
> >>> +               fh->fb.uuid = uuid_null;
> >>> +
> >>>           return fh;
> >>>
> >>> Please let me know if that makes sense to you.
> >>
> >> It does not make sense to me.
> >> I think you may be using the uuid=off feature in the wrong way.
> >> What you did was to change the stored UUID, but this NOT the
> >> purpose of uuid=off.
> >>
> >> The purpose of uuid=off is NOT to allow mounting an overlayfs
> >> that was previously using a different lower UUID.
> >> The purpose is to mount overlayfs the from the FIRST time with
> >> uuid=off so that ovl_verify_origin_fh() gets null uuid from the
> >> first call that sets the ORIGIN xattr.
> >>
> >> IOW, if user want to be able to change underlying later UUID
> >> user needs to declare from the first overlayfs mount that this
> >> is expected to happen, otherwise, overlayfs will assume that
> >> an unintentional wrong configuration was used.
> >>
> >> I updated the documentation to try to explain this better:
> >>
> >> Is my understanding of the problems you had correct?
> >> Is my solution understood and applicable to your use case?
> >>
> >
> > Hi Andre,
> >
> > Sorry to nag you, but if you'd like me to queue the suggested change to 7.0,
> > I would need your feedback soon.
> >
>
> Hey Amir, sorry for my delay. I just had a week out of the office and
> just got back to this.
>
> Our initial test case worked great! We managed to mount both images and
> use overlayfs without a problem after your clarification of where to use
> uuid=off, which should be on the first mount.

Not only on the *first* mount - on *all* the mounts.
Unless you use "uuid=off" consistently, overlayfs will deny the mount.

>
> However, when rebooting to the other partition, the mount failed with
> "failed to verify upper root origin" again, but I believe that I forgot
> to add `uuid=off` somewhere in the mount scripts. I'm still debugging this.

Not sure what you mean by "other partition"
Overlayfs verifies the origin by file handle + UUID.
We allow relaxing UUID check with uuid=off
but isn't it the case for btrfs that the same file in different
clones will have a different file handle, because of different
root_objectid?

        fid->objectid = btrfs_ino(BTRFS_I(inode));
        fid->root_objectid = btrfs_root_id(BTRFS_I(inode)->root);
        fid->gen = inode->i_generation;

That means that you can use "uuid=off" to overcome the
ephemeral nature of the btrfs clone UUID, but you cannot
use it to mount an overlayfs that was created in one btrfs
clone from another clone.

Sorry, no "fileid=off" option, this is out of the question.

You are free to use "index=off" to avoid those requirements,
but the essence of "index=on" is that the lower file can be uniquely
identified and therefore, changing the lower file's unique id is game over.

>
> Anyhow, I see that we are now too close to the merge window, and from my
> side we can delay this for 7.1 and merge it when it gets 100% clear that
> this is the solution that we are looking for.
>

I pushed this patch to overlayfs-next branch.
It is an internal logic change in overlayfs that does not conflict with
other code, so there should not be a problem to send a PR on the
second half of the 7.0 merge window if this is useful.

I think that the change itself makes sense because there was never
a justification for the strict rule of both upper/lower on the same fs
for uuid=off, but I am still not going to send it without knowing that
someone finds this useful for their workload.

Thanks,
Amir.

Powered by blists - more mailing lists