Re: [PATCH v7 06/11] fstests: verify f_fsid for cloned filesystems

On Wed, Jul 22, 2026 at 06:36:13AM +0800, Anand Suveer Jain wrote:
> 
> 
> > This is where I continue getting stuck on this patchset -- fsid is so
> > poorly defined that I don't think the rest of these fsid tests make
> > sense at all.  Nobody mandates that fsid is persistent or stable across
> > remounts.  Nobody even mandates that two cloned filesystems don't have
> > the same fsid value.
> > 
> > The statfs manpage says:
> > 
> > "Nobody knows what f_fsid is supposed to contain (but see below)"
> > 
> > and then:
> > 
> > "The general idea is that f_fsid contains some random stuff such that
> > the pair (f_fsid,ino) uniquely determines a file."
> 
> Which is exactly why we need fstests guardrails.
> Keeps filesystem's implementation consistent across kernel versions.
> Embarrassingly, I introduced a bug around this that is now fixed.
> The commit IDs are in the test cases.
> Thus motivation for this fstests patch.
> 
> > Based on that very weak statement, at most it might make sense to check
> > that two separate and simultaneously mounted filesystems don't end up
> > with the same fsid 
> 
> Yes, for xfs, btrfs and f2fs. However for ext4 cloned filesystems can
> share the same fsid and ino because the images are identical.
> It is then up to the usecase to change the UUID for either filesystem if
> it gets modified.
> Commit ("fstests: add _require_unique_f_fsid() helper") captures this,
> and the link in that commit includes the discussion.
> 
> > just in case there *are* programs foolish enough to
> > use (fsid,ino) as a uniqueness check.
> 
> On the other hand, if a program needs a unique ID, do we currently have
> any way to get one?

I don't think there is a way to get a globally unique identifier for a
filesystem image except for the meta_uuid filesystems, and even then
only if the volume manager resets the user-visible uuid every time it
makes a clone and nobody runs a duplicator.

--D

> Thanks, Anand
> 
> 
>