Re: [PATCH 0/3] fix s_uuid and f_fsid consistency for cloned filesystems

["Theodore Tso" <tytso@mit.edu>]

On Thu, Feb 26, 2026 at 10:23:32PM +0800, Anand Jain wrote:
> 
>               | s_uuid  f_fsid
> --------------|---------------------------
> EXT4          | same    same
> Btrfs         | random  random
> XFS           | same    f(devt)
> EXT4-patched  | same    f(devt)
> Btrfs-patched | same    f(s_uuid,rootid,devt)

I don't *object* to changing ext4 reports since having something that
is unique is probably better.  However, my bigger concern is using
f_fsid in the first place.  It's only 64 bits, and that's really not
enough to gaurantee uniqueness.  And even as you've proposed to change
things, it's not consistent across file systems.  In particular, your
proposed solution mixes s_uuid into btrfs-patched, but not
ext4-patched.  Why?

> Problem
> -------
> Btrfs currently never duplicates s_uuid or f_fsid for cloned filesystems.
> When an fsid collision is detected at mount time, btrfs generates a new
> in-memory fsid (temp_fsid), but this is ephemeral — it changes on every
> mount. This has two consequences:
> 
> 1. IMA (Integrity Measurement Architecture) cannot reliably track the
>    filesystem across mount-cycle, since the f_fsid it sees keeps changing.
>    This does not scale. Whereas on the otherhand if you have same s_uuid
>    on multiple filesystems, monitoring per distint filesystem is lost.

The problem with using f(dev_t) for IMA is that if you have a
removable device (e.g., an SD card), reporting f_fsid as purely being
a function of dev_t means that the if an SD card ejected, and replaced
with another, the fsid_t will manifestly *not* be unique.  So in that
sense, replace f(dev_t) with f(s_uuid) would be worse if you think
"file system unique id" should be unique in the case of removable
storage devices.

If the audit log includes mounts and unmounts, then this might not be
fatal.  But if less-than intelligent system administrator or LLM tries
to analyize an audit log using tools like "grep", it would be pretty
easy for someone to get misled.

I know you were primarily interested in cloned file systems, but I
think we also need to take into account other cases, including ones
where there might be more the file system associated with a block
device over time.

> 2. If we instead allow cloned filesystems to share the same f_fsid (as
>    ext4 currently does), fanotify loses the ability to distinguish
>    between distinct filesystem instances. FAN_EVENT_INFO_TYPE_FID events
>    will fail to resolve to the correct mountpoint when f_fsid values
>    are identical across clones.

My personal opinion is that f_fsuid is just a terrible interface, the
fact that IMA and fanotify used this is regrettable.  I understand why
it happened, because there wasn't anything better, and for many use
cases, it's good enough.   But not all.

So I hope we can just actively discourage anyone else using it.  Given
that exactly it has not been standardized, across different operating
systems, and different file systems for Linux --- hopefully most
people will have already made that choice.

						- Ted