Message-ID: <461fc582-71ba-4238-9696-3d8bdd8a0207@suse.com>
Date: Thu, 15 Jan 2026 18:39:05 +1030
From: Qu Wenruo <wqu@...e.com>
To: Christoph Hellwig <hch@....de>
Cc: André Almeida <andrealmeid@...lia.com>,
 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>, Amir Goldstein <amir73il@...il.com>,
 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,
 linux-btrfs@...r.kernel.org, linux-unionfs@...r.kernel.org,
 kernel-dev@...lia.com
Subject: Re: [PATCH 3/3] ovl: Use real disk UUID for origin file handles



在 2026/1/15 17:53, Christoph Hellwig 写道:
> On Thu, Jan 15, 2026 at 05:21:04PM +1030, Qu Wenruo wrote:
>> So that means let btrfs to convert the temp fsid into metadata uuid, which
>> I think is fine.
> 
> At least in XFS terms, that metadata uuid is the persistent, never
> changing uuid in the metadata headrs.
> 
>> But the problem is that will change the fsid of the new fs, which may or
>> may not be what's expected for the current temp fsid user (they really want
>> two btrfs with the same fsid).
> 
> Which is really dangerous and should not be used in normal operation.
> For XFS with support it with a nouuid option, mostly for historic
> reasons and to be able to change the uuid transactional using an
> ioctl.
> 
>> My initial idea for this problem is to let btrfs not generate a tempfsid
>> automatically, but put some special flag (e.g. SINGLE_DEV compat ro flag)
>> on those fses that want duplicated fsid.
>>
>> Then for those SINGLE_DEV fses, disable any multi-device related features,
>> and use their dev_t to distinguish different fses just like EXT4/XFS,
>> without bothering the current tempfsid hack, and just return the same fsid.
> 
> dev_t is not related to the uuid in any way for XFS, and while I'm not
> an expert there I'm pretty sure ext4 uses the same not dev related uuid
> generation.

My bad, by dev_t I mean bdev holder, which is a pointer to the super 
block of the mounted fs. (And btrfs just recently join this common usage)

> 
>> I'm wondering will that behavior (returning the same fsid) be acceptable
>> for overlayfs?
> 
> 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.

Yeah, although it's possible to mount different devices with same fsid 
separately, I don't think it's really that a good idea either.

Thus I really prefer to have special flags for those "uncommon" use 
cases, other than the current automatically enabled tempfsid feature.

It's like introducing a lot of complexity for a corner case, and that's 
also affecting our common routines.


On the other hand, ext4 allows to mount two cloned fses, mostly thanks 
to the above bdev holder mechanism.


For regular stat() calls, we can still distinguish the two different 
fses with the same fsid, they have two different st_dev members.
But not sure how overlayfs would be able to distinguish such two fses.

> 
>> 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?
> 

For the original thread about A/B partition usage:

https://lore.kernel.org/linux-btrfs/20230504170708.787361-1-gpiccoli@igalia.com/

And

https://lore.kernel.org/linux-btrfs/c702fe27-8da9-505b-6e27-713edacf723a@igalia.com/

Thanks,
Qu

Powered by blists - more mailing lists