linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <anajain.sg@gmail.com>
To: "André Almeida" <andrealmeid@igalia.com>,
	linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org,
	linux-unionfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Cc: kernel-dev@igalia.com, Miklos Szeredi <miklos@szeredi.hu>,
	Amir Goldstein <amir73il@gmail.com>, Chris Mason <clm@fb.com>,
	David Sterba <dsterba@suse.com>,
	"Guilherme G . Piccoli" <gpiccoli@igalia.com>
Subject: Re: [RFC PATCH 0/1] ovl: brtfs' temp_fsid doesn't work with ovl index=on
Date: Wed, 15 Oct 2025 06:04:18 +0800	[thread overview]
Message-ID: <e890fbd0-7b05-47d2-a444-f61409e4bbf5@gmail.com> (raw)
In-Reply-To: <20251014015707.129013-1-andrealmeid@igalia.com>

On 14-Oct-25 9:57 AM, André Almeida wrote:
> Hi everyone,
> 
> When using overlayfs with the mount option index=on, the first time a directory is
> used as upper dir, overlayfs stores in a xattr "overlay.origin" the UUID of the
> filesystem being used in the layers. If the upper dir is reused, overlayfs
> refuses to mount for a different filesystem, by comparing the UUID with what's
> stored at overlay.origin, and it fails with "failed to verify upper root origin"
> on dmesg. Remounting with the very same fs is supported and works fine.
> 
> 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.
> 
> This feature doesn't work well with overlayfs with index=on, as when the image
> is mounted a second time, will get a different UUID and ovl will refuse to
> mount, breaking the user expectation that using the same image should work. A
> small script can be find in the end of this cover letter that illustrates this.
> 
>  From this, I can think of some options:
> 
> - Use statfs() internally to always get the fsid, that is persistent. The patch
> here illustrates that approach, but doesn't fully implement it.
> - Create a new sb op, called get_uuid() so the filesystem returns what's
> appropriated.
> - Have a workaround in ovl for btrfs.
> - Document this as unsupported, and userland needs to erase overlay.origin each
> time it wants to remount.
> - If ovl detects that temp_fsid and index are being used at the same time,
> refuses to mount.
> 
> I'm not sure which one would be better here, so I would like to hear some ideas
> on this.
> 
> Thanks!
> 	André
> 
> ---
> 
> To reproduce:
> 
> mkdir -p dir1 dir2
> 
> fallocate -l 300m ./disk1.img
> mkfs.btrfs -q -f ./disk1.img
> 
> # cloning the disks
> cp disk1.img disk2.img
> sudo mount -o loop ./disk1.img dir1
> sudo mount -o loop ./disk2.img dir2
> 
> mkdir -p dir2/lower aux/upper aux/work
> 
> # this works
> sudo mount -t overlay -o lowerdir=dir2/lower,upperdir=aux/upper,workdir=aux/work,userxattr none dir2/lower
> 
> sudo umount dir2/lower
> sudo umount dir2
> 
> sudo mount -o loop ./disk2.img dir2

At this point, Btrfs assigns a new temporary FSID, but without it,
the test case fails.

Temp FSID support only came in with kernel v6.7, so wondering,
how is this test supposed to work on older kernels?

Thanks, Anand


> 
> # this doesn't works
> sudo mount -t overlay -o lowerdir=dir2/lower,upperdir=aux/upper,workdir=aux/work,userxattr none dir2/lower
> 
> André Almeida (1):
>    ovl: Use fsid as unique identifier for trusted origin
> 
>   fs/overlayfs/copy_up.c | 8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
> 


  parent reply	other threads:[~2025-10-14 22:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-14  1:57 [RFC PATCH 0/1] ovl: brtfs' temp_fsid doesn't work with ovl index=on André Almeida
2025-10-14  1:57 ` [RFC PATCH 1/1] ovl: Use fsid as unique identifier for trusted origin André Almeida
2025-10-14  4:39   ` Christoph Hellwig
2025-10-14  5:13     ` Qu Wenruo
2025-10-14 17:40       ` David Sterba
2025-10-14 17:55         ` André Almeida
2025-10-14 23:46     ` Anand Jain
2025-10-15  1:22       ` Christoph Hellwig
2025-10-20 21:43       ` Dave Chinner
2025-10-21  1:16         ` Anand Jain
2025-10-15 10:52   ` Amir Goldstein
2025-10-14  5:26 ` [RFC PATCH 0/1] ovl: brtfs' temp_fsid doesn't work with ovl index=on Qu Wenruo
2025-10-14 18:24 ` David Sterba
2025-10-14 21:08   ` Qu Wenruo
2025-10-15  0:05     ` Anand Jain
2025-10-15  4:18       ` Qu Wenruo
2025-10-14 22:04 ` Anand Jain [this message]
2025-10-15 11:09 ` Amir Goldstein
2025-10-16  4:57   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e890fbd0-7b05-47d2-a444-f61409e4bbf5@gmail.com \
    --to=anajain.sg@gmail.com \
    --cc=amir73il@gmail.com \
    --cc=andrealmeid@igalia.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=gpiccoli@igalia.com \
    --cc=kernel-dev@igalia.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).