Re: [PATCH v2 3/3] ext4: derive f_fsid from block device to avoid collisions

[Anand Jain <anajain.sg@gmail.com>]

On 9/4/26 21:12, Theodore Tso wrote:
> On Thu, Apr 09, 2026 at 05:45:24PM +0800, Anand Jain wrote:
>>
>> Got it. Do you mean that since both filesystems are identical,
>> statfs(A) and statfs(B) can legitimately return the same values?
> 
> Yes.  f_Fsid can legitimately always be zero (which I believe is the
> case for FreeBSD, but I understand that there are some programs, like
> systemd, which subscribe to the heresy, "All the World's Linux", which
> is a variant of the "All the World's a Vax" or "All the World's SunOS"
> at the beginning of my career :-).
> 
>> I'm not entirely sure what the correct expectation for f_fsid
>> should be.
> 
> That's my point, there *is* no correct expectation, and I don't
> believe there can or should be.  What we should be doing instead is
> actively discouraging people from using f_fsid.  I suspect that's one
> of the reasons why FreeBSD may have chosen to just return zero.
> 
> Which is why I don't think we should be testing this in xfstests's
> generic/791, either.  (Unless we get consensus across file system
> developers abnd willing to make it be a documented behavior as of a
> particular kernel version, and we then adjust the test to skip it if
> it's older than that kernel version, so it doesn't break LTS kernel
> tests.  See below....)
> 

Yes, the idea for generic/79[0-5] was really just to make sure
we don't accidentally change s_uuid or f_fsid behavior without
realizing it. It gives us a baseline for current and LTS kernels
if f_fsid/s_uuid is changed. (Some of the submitted test cases
may still need revision).

>> My initial idea was to make f_fsid behavior consistent across
>> major filesystems so that user space benefits from predictable
>> semantics.
> 
> I'm OK with that, so long as it's unconditional across all file system
> types (ideally) or unconditionally across all major file systems (xfs,
> btrfs, ext4, f2fs) as of a particular kernel version (which is
> probably much more realistic), *and* it is documented in the Linux man
> pages as this is the standard behavior starting with 7.1 (or
> whatever), and that the man page further cautions that programs that
> expect to be portable to other OS's (MacOS, FreeBSD, Solaris, etc.)
> should not count on this behavior.
> 

On second thought, we should perhaps consider a more robust ID,
let's call it `f_fsid_v2`. More on `f_fsid_v2` below.

> But given that you originally stumbled across this with Overlayfs,
> because it was originally using s_uuid, and that didn't work well for
> btrfs, why not change overlayfs to just use s_uuid plus kdev_t in its
> xattr, and just fix the problem for overlayfs?  That has the benefit
> that it will work for all file system types in Linux, not just for
> those where we have changed what f_fsid does.

Using `kdev_t` (or any derivation of it) for persistent storage, such
as Overlayfs xattrs, is problematic. Since `kdev_t` is transient and
inconsistent across reboots or device re-discovery, it could lead to
broken associations.


It seems we've reached the functional limits of f_fsid.
If we want to solve this properly for Overlayfs, NFS handles, or a
complex system monitoring..etc, we need a new identifier let's call
it f_fsid_v2, that meets the following requirements:

  System-wide Uniqueness: Must distinguish between cloned filesystems.

  Persistence: Must remain consistent across reboots/HW re-enumeration.

  Non-On-Disk: Must not be stored on-disk.


One possible implementation for f_fsid_v2 could be:

   f_fsid_v2 =  hash(s_uuid, block_device_serial, [subvol_id])

For pseudo block devices (virtio-blk, loop, nbd, brd,..),
the serial could be derived recursively:

   serial_number = hash(backing_file.f_fsid_v2, backing_file.ino)

Note on Hardware Serials:
 Standard storage protocols (T10, NVMe, SAS) mandate unique,
 persistent serials per LUN. While I've seen T10 protocol
 violations during my time authoring Solaris HBA drivers, I
 believe these outliers shouldn't dictate the design.

This approach provides a system-wide unique ID that is persistent
without being stored on-disk. Effectively solving the cloned
filesystem identity crisis.

Thoughts ?

Thanks, Anand