About statfs.f_fsid

[rusty-snake]

statfs in rustix 0.38 returned the raw linux-raw-sys statfs64 struct. rustix 1.0 changed this to a rustix StatFs struct that uses a Fsid struct for the f_fsid field. For the libc backend this is a alias to libc::fsid_t, the linux_raw backend defines the Fsid struct by itself.

The problem is that this struct is completely useless. Although this is also (kind of) true at the kernel level:

Nobody knows what f_fsid is supposed to contain (but see below).

, the situation in rustix is even more useless.

While you can not be rely on the meaning and ABI of f_fsid across different operating systems, you can use it within one operating system where it has the same meaning and ABI. However this is not really possible with rustix because there are no methods to access the value or do basic operations on it like compare for equality.

Ideas on getting out of this:

• derive PartialEq in linux_raw (for libc backend this is already derived if extra_traits is used) to support comparing of two Fsid instances.
  • This does not fix the problem that you can not create a Fsid without transmute_copy (which should be same because of repr(C) with Copy).
• add a function to expose "the raw value" (for all(?) operating systems "the raw value" can be transmuted to an u64?).
  • Likely impossible for libc backend without transmute(_copy).

[sunfishcode]

Do we know why the libc crate makes fsid_t's fields private? If we're contemplating using transmute to override that decision, perhaps we should just go upstream and propose making those fields public.

Do you have a use case that needs the raw value? Or would PartialEq, Eq, and maybe Hash be enough?

[rusty-snake]

Do you have a use case that needs the raw value? Or would PartialEq, Eq, and maybe Hash be enough?

I migrated by code to use statx.{stx_dev_major,stx_dev_minor,stx_mnt_id} instead of statfs.f_fsid. Works too and does not need unsafe transmute_copy.

My use case was checking for equality of f_fsid but from statfs calls in difference processes. So I needed to serialize it to an u64 (actually u64.to_string()) to pass it to the other process. Thinking again one could also use BuildHasherDefault::<DefaultHasher>::new().hash_one(statfs.f_fsid) if Hash is derived. This should give a stable hash.