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

[Anand Suveer Jain <asj@kernel.org>]

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

Thanks, Anand