Darrick J. Wong [off-list ref] wrote:

Ahah, this is what the f_sb_id field is for.  I noticed a few patches
ago that it was in a header file but was never set.

I'm losing track of which IDs do what...

* f_fsid is that old int[2] thing that we used for statfs.  It sucks but
  we can't remove it because it's been in statfs since the beginning of
  time.

* f_fs_name is a string coming from s_type, which is the name of the fs
  (e.g. "XFS")?

* f_fstype comes from s_magic, which (for XFS) is 0x58465342.

* f_sb_id is basically an incore u64 cookie that one can use with the
  mount events thing that comes later in this patchset?

* FSINFO_ATTR_VOLUME_ID comes from s_id, which tends to be the block
  device name (at least for local filesystems)

* FSINFO_ATTR_VOLUME_UUID comes from s_uuid, which some filesystems fill
  in at mount time.

* FSINFO_ATTR_VOLUME_NAME is ... left to individual filesystems to
  implement, and (AFAICT) can be the label that one uses for things
  like: "mount LABEL=foo /home" ?

Assuming I got all of that right, can we please capture what all of
these "IDs" mean in the documentation?

Basically, yes.  Would it help if I:

 (1) Put the ID generation into its own patch, first.

 (2) Put the notification counter patches right after that.

 (3) Renamed the fields a bit, say:

	f_fsid		-> fsid
	f_fs_name	-> filesystem_name
	f_fstype	-> filesystem_magic
	f_sb_id		-> superblock_id
	f_dev_*		-> backing_dev_*

David